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Description 

[0001] A portion of the disclosure of this patent document contains material, that includes, but is not limited to Ap- 
pendix I, Appendix II, and Figures 10A to 10T, which is subject to copyright protection. The copyright owner has no 

s objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the 
Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever. 
[0002] This invention relates generally to data communication, and in particular to a method and system for enabling 
respective pocket sized mobile two-way data capable wireless communication devices to have interactive two-way 
communication with an application on a server on a wireline computer network. 

10 [0003] For at least the last five years, the wireless communication industry has tried to merge computing with wireless 
communications. This industry wide effort has held the promise of bringing software intelligence to telecommunication 
devices including mobile wireless communications devices such as cellular telephones. 

[0004] After years of research and development, and hundreds of millions of dollars' investment by some of the 
largest companies in the field such as Motorola, AT&T, Sony, Matsushita, Phillips and IBM, the results have been 

15 nothing but disappointing. Typically, the intelligent communication devices resulting from these efforts include both the 
hardware necessary for a computer module and the hardware for a wireless communications module. Examples of 
such products are Simon from IBM and Bell South, MagicLink from Sony, and Envoy from Motorola. 
[0005] A paper by Liljeberg M et al entitled " Optimizing world-wide web for weakly connected mobile workstations: 
and An Indirect Approach" - International Workshop on Services in Distributed and Networked Environments 5 June 

20 1995 pages 132-193 (XP-000764774) describes a communication architecture in which a mobile workstation is con- 
nected to an HTTP agent by means of a slow communication link. The HTTP agent intercepts requests for hypertext 
documents from the workstation and forwards them over a wireless link to an HTTP proxy. The HTTP proxy then poses 
as the client and connects to an appropriate server to ask it to perform the request. The response from the server is 
then sent to the HTTP agent which communicates the response to the workstation. Compression algorithms can be 

25 used for the data transfer between the proxy and the agent or the agent can store data in its local cache, some of this 
data can be pre-fetched. In particular, compression of HTTP headers or transferred data to conserve bandwidth is 
disclosed. 

[0006] A paper by Kaashoek M F et all entitled "Dynamic Documents: Mobile Wireless Access to the WWW" - Pro- 
ceedings, Workshop on Mobile Computing Systems and Applications 8 December 1994 pages 179-184 

30 (XP002016896) describes a communication system for a mobile workstation using wireless communication. When an 
HTTP request is made by the workstation, the document is requested from a server and an exact copy of the response 
is cached. Randomly picked entries from the document cache can be discarded or the entries can be aged. A strategy 
of prefetching documents is disclosed based on the user's history list. Dynamic documents are used which contain 
programs which are run on the workstation and generate the document to be displayed. 

35 [0007] Fundamental design and cost problems arising directly from the approach taken by the designers of these 
intelligent communication devices have limited widespread market acceptance of these devices. The combination of 
a wireless communication module with a computing module leads to a device that is too bulky, too expensive, and too 
inflexible to address the market requirements. 

[0008] The combination of the two modules is too large and too heavy to fit in the user's pocket. Pocket size is a key 
40 requirement of the mobile communication market which remains unmet by these devices. 

[0009] In addition, the cost of these devices is close to the sum of the cost of the computer module and of the 
communications module, which is around a one thousand dollar end-user price. Market research indicates that the 
market for intelligent wireless communications devices is at prices of around $300. Even with a 20% compound cost 
decline, it would take five years for the combination units to meet today's customer's price requirements. It is therefore 
45 unlikely that devices designed by combining a computer and a wireless module, no matter how miniaturised and cost 
reduced, can satisfy the cost requirement of the market during this decade. 

[0010] To succeed in the market place, intelligent wireless communication devices must be able to support a wide 
variety of applications specific to each market segment. Typically, these applications must be added to the device by 
the end-user after purchase. Thus, the device must provide a method for loading the initial application and for subse- 

50 quent updating of the application. 

[0011] The price sensitivity for intelligent communication devices and the size limitations means that an intelligent 
communication device cannot support the amount of core memory (RAM), a hard disk or non-erasable memory, or a 
traditional floppy disk drive, commonly found on computers. These limitations close the traditional routes for delivering 
new applications or updates to intelligent communications devices. 

55 [0012] As a result, the current crop of intelligent communication devices run only the few applications which were 
burned into their ROMs at the factory or which are contained in a ROM card plugged into a slot designed for this 
purpose. This scheme lacks the flexibility needed to run the thousands of applications required to address the frag- 
mented requirements of the market and provides no simple method for updating the applications after the device has 
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been sold. 

[0013] Two other communication oriented attempts at bringing intelligence to telephones are Short Messaging Serv- 
ice (SMS) and Analog Display Service Interface (ADSI). SMS specifies how messages are delivered to and from a 
cellular telephone and how the cellular telephone should store the messages. SMS also defines some simple process- 
s ing which the cellular telephone can perform on the message, such as calling a telephone number embedded in the 
message. 

[001 4] SMS's architecture is similar to that of paging networks with the difference that devices implementing the SMS 
architecture operate over the control channel of the cellular telephone network. SMS is deployed primarily in Europe 
over the GSM network. 

10 [0015] SMS messages are not delivered in real time. The time delays can range from 30 seconds up to 10 minutes, 
which makes SMS unsuitable for real time applications. The main purpose of SMS is the delivery of messages. SMS 
does not specify an application protocol or cellular telephone application module which further restricts its usefulness 
in running applications on cellular telephones. After a few years of deployment in Europe, SMS implementations have 
been limited to notification services such as two-way paging and voice mail notification. 

15 [0016] SMS as a medium is unsuited to building applications which allow the retrieval, manipulation, and storage of 
information. This is the reason why the industry giants have not turned to SMS in their quest to add intelligence to 
cellular telephones, but have consistently attempted to combine a computer module with a wireless communications 
module. 

[0017] ADSI was designed as an extension to Interactive Voice Response Systems. ADSI allows a smart telephone 

20 with a small screen to display prompts to assist users in choosing among various options. By using visual prompts 
instead of cumbersome voice prompts, ADSI is thought to make the use of interactive voice services easier and faster. 
[0018] ADSI allows data to be sent from the service provider to the telephone in the form of screens. ADS also allows 
the telephone to respond through touch tone signalling with a special coding to describe the full alphanumeric character 
set. With ADSI, a telephone is primarily a passive device. Services send text screens to the telephone, and the tele- 

25 phone sends back sort strings indicating the choices the user made from the text screen. 

[0019] ADSI makes no provisions for performance of processing in the telephone. As a result, ADSI generates a 
high traffic load on the telephone network since each user input is sent back to the service for processing. This makes 
ADSI unsuitable for wireless networks where bandwidth is a premium and "air efficiency" is one of the most sought 
after qualities. The lack of processing capability in the telephone and the high bandwidth requirements of ADSI have 

30 prevented it from being considered by the industry for implementing intelligent wireless devices. 

[0020] Up to now, intelligent communication devices have combined a computing module with a wireless communi- 
cations module. However, to gain widespread acceptance, a two-way data communication device with processing 
capability and the ability to run a wide variety of differing user applications is needed. In addition, such a device should 
be comparable in size, cost, and weight to a cellular telephone. 

35 [0021] According to the present invention there is provided a method, implemented in a network node coupled to a 
wireless telecommunications network and to a wireline computer network, to enable respective pocket sized mobile 
two-way data capable wireless communication devices to have interactive two-way communication with an application, 
the method comprising:- 

40 receiving over the wireless telecommunications network a request from a said mobile device to execute an appli- 

cation on a server on the wireline computer network; 

sending the request over the wireline computer network to the server to access said application; characterised by 
receiving a response over the wireline computer network according to the execution of said accessed application, 
the response consisting of information to be interpreted by the mobile device and whereby an interactive user 
45 interface is generated therefrom and whereby another request is generated therefrom to said or another server 

according to the use made of that generated user interface; and 

sending the response to said a mobile device over the wireless telecommunications network. 



50 



[0022] According to another aspect of the present invention there is provided a network node comprising:- 



a first communication interface to communicate with respective pocket sized mobile two-way data capable wireless 
communication devices over a wireless telecommunications network; 

a second communication interface capable of communication with a server over a wireline computer network; and 
a processor coupled to the first communication interface and the second communication interface to execute a 
55 process, the process including:- 

receiving over the wireless telecommunications network a request from a said mobile device to execute an 
application on a said server on the wireline computer network; 
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sending the request over the wireline computer network to said server to access said application; 
characterised by 

s receiving a response over the wireline computer network according to the execution of said accessed appli- 

cation, the response consisting of information to be interpreted by the mobile device and whereby an interactive 
user interface is generated therefrom and whereby another request is generated therefrom to said or another 
server according to the use made of that generated user interface; and 
sending the response to said a mobile device over the wireless telecommunications network. 

10 

[0023] Additional advantageous features are defined in the subsidiary claims. 

[0024] A two-way data communication device of this invention, such as a cellular telephone or a two-way pager, may 
include a client module having lightweight resources that communicates with a server computer over a two-way data 
communications network. The principles of this invention can be used with a wide variety of two-way data communi- 
15 cations networks. For example, two-way data communications networks for cellular telephones that may be used in- 
clude a cellular digital packet data network as well as TDMA, CDMA, and GSM circuit switched data networks; and 
the AMPS analog cellular network with a modem. Similarly, for two-way pagers, two-way data communications networks 
include PACT, the new AT&T endorsed two way paging standard, or other priority two-way paging networks with data 
transport capability. 

20 [0025] Using the two-way communications device that includes the client module, a user can provide information to 
the server computer, retrieve information from the server computer, provide data to an application on the server com- 
puter which uses the data and provides information to the two-way communications device, or sends the information 
to another location. The functionality provided to the user of the two-way communication device is limited only by the 
applications available on a server computer that is accessible to the user over the two-way data communications 

25 network. 

[0026] This invention allows for the first time two-way communications devices such as cellular telephones and two- 
way pagers to become open application platforms which in turn empowers software developers to deliver value-added 
applications and services to any two-way communication device which utilize the principles of this invention. This is a 
radical shift from the current situation where telephones and two-way pagers are closed, proprietary systems. Conse- 

30 quently, an even playing field is created for the market to invent new uses for two-way communication devices and for 
two-way communication networks. Any entity from corporations to individuals can make new applications available to 
the installed base of two-way data communication devices used with this invention without physical modification or 
addition to the two-way communication device. Years after purchase, a two-way communication device suitable for 
use with this invention will run all the applications which were developed since its purchase. 

35 [0027] Further, all these application are available without the end user having to add anything or make any modifi- 
cation to the two-way communication device. Also, the applications are independent of the two-way data communication 
network. The applications do not depend on any feature of the two-way data communication network. Thus, the appli- 
cations are unaffected by a change in the two-way data communication network. 

[0028] Also, the applications on the server computer are independent of the two-way data communication device 
40 with which the server computer is interacting. An application on the server computer can communicate with any two- 
way data communication device that includes a sitable client module and a network interface module to transmit data 
over, and receive data from the two-way data communication network. These two features mean that an investment 
in developing an application is insulated from either advances in two-way data communication devices, or advances 
in two-way data communication network technology. 
45 [0029] The two-way data communication device of this invention may utilize a client module to transmit a message 
including a resource locator selected by the user over the two-way data communication network to a server on a server 
computer on the computer network. For example, the computer network can be a corporate wide area network, a 
corporate local area network, the Internet, or any combination of computer networks. 

[0030] The server processes the message, i.e, executes the application addressed by the resource locator and 
50 transmits a response over the two-way data communication network to the two-way data communication device, which 
stores the response in a memory. The client module interprets the response and generates a user interface using 
information in the response. In one embodiment, the user interface includes at least one user data input option that is 
associated with a resource locator. In another embodiment, the user interface is a display. 

[0031] The resource locator associated with the at least one user data input option can address any one of a wide 
55 variety of objects. In one embodiment, the resource locator associated with the at least one user data input option 
addresses an object on the server computer that transmitted the response. In another embodiment, the resource locator 
addresses an object on another server computer coupled to the two-way data communication network. In yet another 
embodiment the resource locator addresses an object stored in the two-way communication device. 
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[0032] When the user selects the at least one user data input option, the client module interprets the selection and 
if required, appends any input data to the resource allocator associated with the at least one user data input option. 
The client module transmits a message including the resource locator with any appended input data to the server 
computer. Alternatively, the resource locator with any appended data can be addressed to another server computer, 
s or can address an object stored in the two-way communication device. If the resource locator addresses an object on 
a server computer, the client module provides the message to the network interface module which in turn transmits 
the message over the two-way data communication network. 

[0033] Thus, in this embodiment, the message originally transmitted to the two-way data communication device 
included all the information necessary for the client module to generate the user interface, to associate the user selection 
10 and any data entered with a particular resource locator, and to transmit the appropriate resource locator in a subsequent 
message. The client module includes an interpreter that processed the information in the message. Since the message 
included all the information needed by the client module, the server computer that transmitted the message retained 
no state information concerning the message. Consequently, the server computer is defined as a stateless server 
computer. 

15 [0034] An important aspect of this invention is that the message includes all information necessary for the client 
module to generate the user interface and a particular user interface can be independent from other user interfaces. 
Unlike prior art systems that gave the user a predetermined menu from which to select items, or limited the user to an 
E-mail like format, according to the principles of this invention, the user interfaces and possible interactions available 
to the user are determined only by the applications that developers make available. The possible interactions and user 

20 interfaces for one application can be totally different and independent from the possible interactions and user interfaces 
of another application. Thus, a cellular telephone and a two-way pager both truly become an open platform. 
[0035] These features of the invention are a significant departure from prior art systems. Typically, in the prior art, 
use of a particular application on a particular platform required that the application be compatible with the operating 
system on that platform. Further, each time a new version of the application was released, the user was required to 

25 take steps to update the application on the user's platform. Further, if the user of the platform did not modify the operating 
system as new versions of the operating system were released, at some point in time, the platform would no longer 
be capable of processing a new version of an application that requires a current version of the operating system. 
[0036] This invention eliminates these problems. As explained above, the client module in the two-way data com- 
munication device functions an interpreter. The application on the server computer provides all information necessary 

30 for the interpreter to generate a user interface on the two-way data communication device, and in response to user 
selections or data input using the user interface, to route message to an appropriate server, i.e, either the server that 
sent the original information or another server. 

[0037] Thus, the client module only interprets this information and interacts appropriately with the hardware of the 
two-way data communication device. Consequently, to update an application requires only changes on the server 
35 computer and not changes in each two-way data communication device that communicates with that server computer. 
This invention eliminates the usual requirement for distribution of application software, and application software updates 
to the end user of the two-way data communication device. 

[0038] In one embodiment, a two-way data communication system for communication between a server computer 
and a two-way data communication device selected from a group consisting of a cellular telephone and a two-way 

40 pager, includes a two-way data communication network, a server computer coupled to the two-way data communication 
network, and a two-way data communication device coupled to the two-way data communication network. The server 
computer includes a two-way data communication interface module coupled to the two-way data communication net- 
work, and a server coupled to the two-way data communication interface module. The server receives a message 
including a resource locator from the two-way data communication network. The resource locator includes an address 

45 of the server computer and of an application on that server computer. The server processes the message using the 
resource locator. In this embodiment, the server transmits a response to the message over the two-way data commu- 
nication network. 

[0039] The two-way data communication device, selected from the group consisting of a cellular telephone and a 
two-way pager, includes a network interface module coupled to the two-way data communication network, and a client 
50 module coupled to the network interface module. The client module transmitted the message including the resource 
locator to the server over the two-way data communication network. The client module also processes the response 
to the message from the server. The response includes information for a user interaction over the two-way data com- 
munication network. 

[0040] The client module which may be used with this invention is lightweight, and thus requires only lightweight 
55 resource in a two-way data communication device. Consequently, the client module can use existing resources in such 
a device and therefore does not add to the cost of the two-way data communication device. 

[0041] In one embodiment, the interpreter within the client module includes a plurality of managers including a user 
interface manager coupled to a display of the two-way data communication device where the user interface manager 
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handle interactions with the display. The user interface manager also is coupled to a keypad of the two-way data 
communication device and handles interactions with the keypad. Herein, a keypad can be a telephone keypad, the 
keys found on a two-way pager, or other data input interface of a two-way communication device. 
[0042] In one embodiment, the response generated by the server computer includes a plurality of resource locators 
s and at least one of the plurality of resource locators includes an address to another server coupled to the communication 
network. 

[0043] Examples of the present invention will now be described with reference to the accompanying drawings, in 
which:- 

10 Figure 1 illustrates one embodiment of the wireless telecommunications, (or airnet) network of this invention that 

includes the two-way data communication devices of this invention. 

Figures 2A to 2H are illustrations of a series of screen displays of a two-way data communication device of this 
invention that illustrate one application of the principles of this invention. 

Figures 3A to 3F are illustrations of a series of screen displays of a two-way data communication device of this 
15 invention that illustrate a second application of the principles of this invention. 

Figures 4A to 41 are illustrations of a series of screen displays of a two-way data communication device of this 
invention that illustrate yet another application of the principles of this invention. 

Figure 5 illustrates another embodiment of the airnet network of this invention that includes the two-way data 
communication devices of this invention and an airnet network translator. 
20 Figure 6 is a block diagram of a mobile wireless communication device that includes the client and support modules 

which may be used with this invention. 

Figure 7 is a more detailed diagram of the mobile wireless communication device and a server computer within 
the airnet network architecture of this invention. 

Figures 8A to 8D are a process flow diagram showing the process performed by the client in the mobile wireless 
25 communication device and the server on the server computer of Figure 7. 

Figure 9 is a diagram of a mobile wireless communication device of this invention that includes a novel predictive 
text entry system. 

Figures 10A to 10Tareone embodiment of a letter frequency table. 

Figure 1 1 is a process flow diagram for one embodiment of a data entry process that includes the novel predictive 
30 data entry process of figure 9. 

Figure 12 is a more detailed diagram of the mobile wireless communication device and the airnet network translator 
within the airnet network architecture of another embodiment of this invention. 

Figure 1 3 is a process flow diagram showing the various processes performed by the airnet network translator of 
Figure 12. 

35 Figure 14 is a diagram illustrating the various module managers included in one embodiment of a client module 

which may be used with this invention. 

[0044] Herein, objects with the same reference numeral are the same object. Also, the first number of a reference 
numeral indicates the Figure where the object first appeared. 

40 

DETAILED DESCRIPTION 

[0045] With this invention, a novel airnet network 150, i.e., a two-way data communication network, interconnects 
one or both of two-way data communication devices 100 and 101 , with a wide variety of computer networks 120, 130, 

45 and 140, for example. As explained more completely below, each two-way data communication device 100 and 101 
can be configured to transmit data to and receive data from any desired combination of computers on computer net- 
works 120, 130, and 140. Airnet network 150 is the two-way data communication path from the two-way data commu- 
nication device to the particular computer that is accessed by the user of that two-way data communication device. 
[0046] Each wireless communication device 100 used with this invention can communicate over airnet network 150 

50 with any server computer 121 , 131 , and 141 on airnet network 150 that includes at least one application that commu- 
nicates and interacts with the processes that are included within device 100. Thus, device 100 can access information 
on the computer network and provide information to the computer network. Similarly, a two-way pager 101 used with 
this invention, can communicate over airnet network 150 with any of server computers 121 , 131 , and 141 that includes 
at least one application that communicates and interacts with the processes that are included within device 101 . 

55 [0047] As explained more completely below, an application on a server computer can be accessed by any two-way 
data communication device that can communicate with that server computer. The application is independent of the 
particular type of two-way data communication device that is used to access the application and independent of the 
particular two-way data communication network used. This means that a user can access an application from anywhere 
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so long as the user has a two-way data communication device that can communicate with the server computer. 
[0048] In one embodiment, a process on wireless communication device 100 is configured as a client process and 
the applications on server computers 121,131 and 141 on airnet network 1 50, that communicate with the client process, 
are server processes. This architecture allows some of the processing burden to be moved away from cellular telephone 

s 100, across airnet network 150, to a server module on any computer on airnet network 150. 

[0049] Specifically, a wireless communication device 100 e.g., a cellular telephone, with a telephone like keypad, 
communicates via a data capable cellular telephone network 110, e.g., a cellular digital packet data telephone network, 
with an application on a server computer on a computer network that has an interface to data capable cellular telephone 
network 110. For example, the computer network can be a corporate wide area network 120, a corporate local area 

10 network 130, or perhaps the Internet 140. 

[0050] Similarly, a two-way pager 101 communicates via a two-way pager network 1 1 1 with an application on a server 
computer on a computer network that has an interface to two-way pager network 111. Again, for example, the computer 
network can be a corporate wide area network 120, a corporate local area network 130, or perhaps the Internet 140. 
[0051] In both two-way data communication devices 100 and 101 , the client process is stored as a client module in 

15 the device and the execution of the client module on a microcontroller in the device is sometimes referred to as the 
client process. The client process performs important processing functions locally. This allows the communication 
between the client process, hereinafter sometimes referred to as simply client, and the server process, hereinafter 
sometimes referred to as server, to be minimized and the server computing requirements to grow slowly as the number 
of clients, i.e., users, grows. 

20 [0052] The client module is small, e.g., under 64 KByte, and requires only low processing power congruent with the 
memory chips and built-in microcontrollers in two-way data communication devices such as cellular telephone 1 00 and 
two-way pager 101. Thus, unlike the prior art attempts at an intelligent telephone, the cost, size, and battery life of 
either cellular telephones or two-way pagers suitable for use with this invention are not adversely affected. 
[0053] While client/server architectures have been used extensively in computer networks, a client/server architec- 

25 ture implemented using two-way communication data devices such as cellular telephone 100 or two-way pager 101 
yields new and unexpected results. This invention allowsfor the first time a wide variety of two-way data communication 
devices including but not limited to cellular telephones and two-way pagers to become open application platforms which 
in turn empowers software developers to deliver value added applications and services to any two-way data commu- 
nication device suitable for use with this invention. 

30 [0054] This is a radical shift from the current situation where cellular telephones and two-way pagers are closed, 
proprietary systems. Consequently, an even playing field is created for the market to invent new uses for cellular 
telephones and data capable cellular networks, and for two-way pagers and two-way pager networks. 
[0055] Any entity from corporations to individuals can make new applications available to the installed base of data 
ready cellular telephones and two-way pagers used with this invention without physical modification or addition to the 

35 devices. Years after purchase, a two-way data communication device suitable for use with this invention can run all 
the applications which were developed since its purchase. Further, all these applications are available without the user 
having to add anything or make any modification to the two-way data communication device. These features of the 
invention are a significant departure from prior art systems. Typically, in the prior art, use of a particular application on 
a particular platform required that the application be compatible with the operating system on that platform. Further, 

40 each time a new version of the application was released, the user was required to take steps to update the application 
on the user's platform. Further, if the user of the platform did not modify the operating system as new versions of the 
operating system were released, at some point in time, the platform would no longer be capable of processing a new 
version of an application that required a current version of the operating system. 

[0056] Also, small devices, such as cellular telephones or pagers, usually do not have card slots, floppy or hard disk 
45 drives, or other means commonly found on computers to add or update applications. This limitation has led prior art 
attempts at intelligent communication devices to design closed systems with fixed functionality. Such devices can 
neither adapt nor be adapted to the fast changing requirements of the market place and so have not met with market 
success. 

[0057] This invention eliminates these problems. The client process in the two-way data communication device func- 
50 tions an interpreter. The application on the server computer provides all information necessary for the interpreter to 
generate a user interface on the two-way data communication device, and in response to user selections or data input 
using the user interface, to route messages to an appropriate server, i.e, either the server that sent the original infor- 
mation or another server. 

[0058] Thus, the client process only interprets this information and interacts appropriately with the hardware of the 
55 two-way data communication device. Consequently, to update an application requires only changes on the server 
computer and not changes in each two-way data communication device that communicates with that server computer. 
This invention eliminates the usual requirement for distribution of application software, and application software updates 
to the end user of the two-way data communication device. 
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[0059] For example, if initially, two-way pager 101 receives a response to a message from an application on server 
computer 121 on corporate wide area network 120, the interpreter in two-way pager 101 generates a user interface 
on display screen 106 using information in the message. As described more completely below, options presented in 
the user interface can allow the user to access information, or provide information to any one, any combination of, or 

5 all of networks 120, 130, and 140. 

[0060] Specifically, in the response to the message from two-way pager 101, the application initially accessed on 
server computer 121 included resource locators for applications on each of networks 120, 130, 140, typically common 
gateway interface programs, accessible to the user of pager 101 as well as information required to generate the user 
interface. Consequently, when the user makes a particular selection or enters data, the interpreter accesses the ap- 

10 propriate resource locator and appends any necessary data to the resource locator. The client transmits a message 
including the resource locator to the appropriate server. 

[0061] As shown by this example, the applications on networks 120, 130, 140 send to the two-way data communi- 
cation device all information necessary to generate a user interface, and to process all user input. Consequently, only 
an application must be changed to update the information provided to the two-way data communication device. 
15 [0062] In addition, since all the information needed by the client to generate a user interface and all information 
necessary for the client process to respond to any input data is included in the message, the computer server does 
not retain any state information concerning the information transmitted to the client process. Consequently, the com- 
puter server is stateless. 

[0063] Both two-way data communication devices 100 and 101, that utilize airnet network 150, include a data com- 
20 munication capability, a display screen, preferably a multi-line display screen, and storage capability for the processes 
of this invention in an on-board memory, and for the message being processed. Nearly every data capable cellular 
telephone, e.g., a telephone that utilizes a cellular digital packet data network, includes excess on-board memory 
capacity and a multi-line display screen. These hardware resources are often available, but unused in a data capable 
cellular telephone because of the indivisibility of memory chip packages. The suitability for use with the processes of 
25 this invention of such cellular telephones therefore has very little effect on the cost, size, and power consumption of 
the cellulartelephone. Similarly, the suitability for use with the processes of this invention of two-way pagers that include 
a microcontroller and memory, has very little effect on the cost, size, and power consumption of these devices. 
[0064] Thus, unlike prior art approaches that attempted to combine a computer module and a wireless communication 
module in a single package, this embodiment of the invention preferably utilizes the memory and processing power 
30 that currently exists in the cellular telephone 100, two-way pager 101, or other wireless two-way data communication 
device. This approach limits the cost of the resulting device and overcomes many of the problems of the prior art 
devices, e.g., the size and weight of the two-way data communication device is not changed, and, as explained above, 
updating user applications is removed from cellulartelephone 100, and two-way pager 101. 

[0065] In particular, unlike devices produced by previous industry attempts at combining computing modules and a 
35 wireless cellular module, two-way data communication devices suitable for use with this invention are size and cost 
competitive with voice-only telephones and can, for the first time, satisfy the market cost and size requirements for an 
intelligent cellular telephone, for example. 

[0066] The incremental cost of supporting interactive applications on cellulartelephone 100 and two-way pager 101 
is reduced to at most a slightly larger screen that is required to display the application to the user. This is a fraction of 

40 the cost of adding a complete computer module to a cellular telephone, for example. 

[0067] The incremental power consumption required to support this invention is also very small, as the incremental 
memory and screen required are small consumers of power compared to the cellular radio itself. Intelligent two-way 
data communication devices built for use with this invention are not expected to have a significantly lower battery life 
than standard cellular telephones, or two-way pagers, for example. 

45 [0068] The configuration and processes of the client process in two-way data communication devices 100 and 101 
are similar when the differences in the devices and the two-way data communication network over which the devices 
communicate are considered. Consequently, in the following description, the operation of data-ready cellulartelephone 
100 is considered. The same or similar operations can be performed on two-way data communication device 101 . The 
main difference is that some device dependent features within the client module must be changed to accommodate 

50 the particular hardware used in the two-way communication device. However, the client module architecture described 
more completely below limits the number of changes that must be made. 

[0069] As indicated above, in response to user actions, wireless communication device 100 transmits a message, 
typically a data request, to a server computer 121 on computer network 120 and receives a response to the message. 
Alternatively, the user action can result in directions to server computer 121 on computer network 120 to transmit the 
55 response to the message to another location or to another user. Also, wireless communication device 1 00 can receive 
a message from any one of the computers coupled to airnet network 150. 

[0070] An important aspect of this invention is that the client module interpreter in wireless communication device 
100 generates a user interface by which the user can both initiate and receive messages from a variety of applications. 
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The interactions take place in real-time and are not limited by the client module interpreter. The uses of wireless com- 
munication device 1 00 are limited only by the availability of applications on server computers. 
[0071] The applications available are determined by application developers. Prior to considering one implementation 
of the invention in further detail, several illustrative examples of applications that can be implemented with this invention 
s are described. These applications are illustrative only and are not intended to limit the invention to the particular ap- 
plications and features described. 

[0072] In one use, the user configures cellular telephone 100 to access server computer 121 on XYZ corporate wide 
area network 1 20. In response to the access by the user, server computer 121 transmits a card deck to cellular telephone 
1 00 over data capable cellular telephone network 1 1 0. As explained more completely below, a card deck includes one 

10 or more cards, and each card is interpreted by the client module to generate a user interface screen. 

[0073] In the embodiment illustrated in Figure 2A, the initial card deck transmitted to cellular telephone 1 00 includes 
an introductory display card and a choice card. Figure 2A is an example of introductory screen display 200 that is 
generated on display screen 105 by the client process in cellular telephone 100 by interpreting the display card. As 
used herein, a display screen is the physical display apparatus in a two-way communication device. A screen display 

15 is the image presented on the display screen. 

[0074] In this embodiment, display screen 105 is a pixel display that displays graphics. In another embodiment, 
display screen 105 displays only text and so the graphics would not appear on display screen 105. Screen display 
200, and other screen displays described more completely below, include a horizontal arrow, i.e., a multi-card deck 
indicator, to communicate to the user that the current deck includes another card. The inclusion of screen indicators, 

20 such as the multi-card deck indicator, to communicate with the user is optional. The functionality of this invention is 
independent of such screen indicators. 

[0075] When the user presses a predetermined key, or key sequence, the client process in cellular telephone 100 
interprets the next card in the card deck, i.e., the choice card, and in turn generates a menu 201 (Fig. 2B) of items that 
can be accessed by the user. In this embodiment, each of the menu items is available on server computer 121 to the 

25 user who, in this example, is a representative of XYZ corporation visiting ABC Designs. 

[0076] As explained more completely below, each of the menu items is associated with a resource locator that in- 
cludes an address of the particular object associated with that menu item, typically an address to a common gateway 
interface program on server computer 121. In general, a resource locator includes an address and may include ap- 
pended data. The address can be to a local object within the two-way data communication device or to a remote object 

30 on a server computer. As is known to those skilled in the art, the common gateway interface is an Internet standard 
that is used to dynamically generate information, e.g., cards. In view of this disclosure, other techniques to generate 
dynamic cards could be used. 

[0077] Initially, the highlighting of the first line of menu 201 is not present. When a key on the keypad of cellular 
telephone 100 is pressed, the menu item corresponding to that key is highlighted on screen 105. Thus, menu 201 
35 shows the first item highlighted to indicate that the one key was pressed by the user. However, highlighting a selected 
item is a feature that is specific to this example, and in general is not required to implement the invention. Other methods 
can be used to indicate the user's choice on display screen 105 such as an arrow pointing at the choice, if such an 
indication is desired. 

[0078] After the one key is pressed, the user presses a predetermined key, e.g., an enter key, to verify the selection. 

40 Alternatively, in another embodiment, the verification of the selection is not required. In both embodiments, the resource 
locator for the selection is transmitted to server computer 121 by the client process in cellular telephone 100 over data 
capable cellular telephone network 110. In response to the selection, server computer 121 processes the message 
containing the selection, and in this embodiment, transmits another card deck to cellular telephone 100. 
[0079] The client process in cellular telephone 1 00 interprets the first card in the deck received from server computer 

45 121, which is a choice card, and generates a screen display 202, that includes a second menu as illustrated in Fig. 
2C, on display screen 105. Initially, none of the items in the second menu are highlighted. 

[0080] Notice that screen display 202 includes a header, that describes the selection made by the user on screen 
display 201 , in addition to the second menu of choices available to the user. A multi-display screen card indicator 203, 
e.g., in this embodiment, a hand icon with a finger pointing down, shows that the screen associated with the current 
50 choice card includes additional items that are not shown on display screen 105. Herein, a screen can be larger than 
the number of lines available on display screen 1 05 and so the user must scroll the screen display to view the complete 
screen. 

[0081] Thus, to view the additional items, the user presses a first screen scroll key, e.g., a next key, on cellular 
telephone 100. In this embodiment, when the first screen scroll key is pressed, each line of the display is rolled up one 
55 line. The resulting display has an icon with a finger pointing up (not shown) if the menu requires only two screen 
displays. If the menu requires more than two screen displays, the second screen display of the menu would have two 
icons, one with a finger pointing up, and another with a finger pointing down. To scroll between the various lines in the 
second menu, the user uses the first screen scroll key, and a second screen scroll key. 
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[0082] If the user displays the last line of a card, e.g., the last line in the second menu, and presses the first screen 
scroll key nothing happens. In this embodiment, the user must make a choice before the next card is available. 
[0083] Screen display 202 also includes representations of two soft keys, a home key 204, and an info key 205. In 
this example, these soft keys are defined only for the card used to generate screen display 202. When the user presses 
s a predetermined key sequence, the home key is highlighted to indicate the selection. In this embodiment, when the 
home key is selected, the user is returned to screen display 200. In another embodiment, the user could be returned, 
for example, to a home screen display that is displayed each time the user activates cellular telephone 100 for use on 
airnet network 150. 

[0084] The home key is associated with a pointer, that in one embodiment is a resource locator, and the card ad- 
10 dressed by the pointer is displayed by the client process when the home key is selected by the user. Specifically, if the 
pointer is to a card in the current deck, the client process simply displays that card. If the pointer is to other than a card 
in the current deck, the client process in cellular telephone 100 retrieves the deck containing the card at the location 
identified by the pointer. The location could be, for example, either a memory in cellular telephone 100, or a memory 
in computer 121 . 

15 [0085] Similarly, when the user presses another predetermined key sequence, the info key is highlighted to indicate 
the selection. In this embodiment, when the info key is selected, a help screen is displayed for the user that describes 
the possible selections. The particular contents of the help screen are determined by the provider of the service. Spe- 
cifically, a pointer is associated with the info key and when the info key is depressed by the user, the information stored 
at the location identified by the pointer is retrieved and interpreted by the client process in cellular telephone 100. 

20 [0086] Returning to the menu in Figure 2C, since the user wants to determine the status of an order, the user pushes 
the two key on the keypad of cellular telephone 1 00. In response to the key press, the second choice in the menu is 
highlighted as shown in Figure 2C. In response to verification of the key press, e.g., the user presses a predetermined 
key sequence, cellular telephone 100 transmits a check open order request to computer 121, i.e, the client process 
transmits a message that includes a resource locator associated with the menu item selected by pressing the two key. 

25 [0087] In response to the check open order request, computer 121 transmits yet another card deck to cellular tele- 
phone 100. The client process in cellular telephone 100 interprets this deck, that is an entry card, and in turn generates 
a purchase order number entry screen display 206 (Fig. 2D) on display screen 105. Notice that screen display 206 
has a previous soft key 207 and a fax soft key 208. Again, each of these soft keys has an associated pointer and the 
information stored at the location identified by the pointer is retrieved and interpreted by the client process when the 

30 user selects the soft key. 

[0088] In this example, the user does not select a soft key, but rather the user enters the purchase order number as 
shown in Figure 2E using the keypad of cellular telephone 100. The user enters only the various numbers. The client 
process formats the number and inserts the dashes as shown in Figure 2E. 

[0089] After the purchase order is entered, the user presses a predetermined key sequence to indicate to the client 

35 process that entry of the purchase order number is complete. Notice that the user is entering data and not simply 
selecting a menu item. The user is utilizing cellular telephone 100 as if cellular telephone 1 00 was a computer connected 
to network 120, but, as explained more completely below, cellular telephone 100 is similar to a standard digital data 
capable cellular telephone that communicates over data capable cellular telephone network 1 1 0. Specifically, cellular 
telephone 100 is not a combination of a computer module and a wireless communication module as in prior art attempts 

40 to create an intelligent telephone. 

[0090] In addition, the user enters data using only the standard cellular telephone keypad. Thus, cellular telephone 
100 eliminates the need for a computer keyboard or for a sophisticated touch screen that recognizes motion of a 
pointing object. This is important to maintaining the size, weight, and power requirements of cellular telephone 100 
similar to those of a voice-only cellular telephone. In one embodiment, to facilitate data entry, as explained more com- 

45 pletely below, cellular telephone 1 00 includes a text prediction process that reduces the number of key strokes required 
to enter text data. In this embodiment, the text prediction process is turned on or off for each entry card. 
[0091] In response to entry of the purchase order number, the client process transmits a request to server computer 
121 for the particular purchase order. Specifically, the client process appends the entered data to a resource locator 
and transmits a message containing the resource locator to server computer 121 . Server computer 121 , in response 

50 to the message, retrieves the appropriate purchase order and transmits the purchase order as a card deck to the client 
process in cellular telephone 100 over airnet network 150. 

[0092] The client process interprets the card deck and generates a screen display 209 (Fig. 2F). Initially, fax key 208 
is not highlighted in screen display 209. 

[0093] Notice that screen display 209 includes multi-display screen card indicator 203 to show the user that the 
55 purchase order screen contains more information that can be displayed at one time on display screen 105. 

[0094] After the user reviews the purchase order, the user presses the key sequence for fax key 208 and in response, 
fax key 208 is highlighted as illustrated in Figure 2F. 

[0095] In response to selection of fax key 208, the client process retrieves the card deck at the location identified by 
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the pointer associated with fax key 208. If the location is on server computer 121 , the client process transmits a message 
including a resource locator to server computer 121 and in response to the message, server computer 121 transmits 
back yet another card deck. If the location is on a server computer other than server computer 121, the client process 
transmits a message including a resource locator to that server computer and in response to the message, that server 
s computer transmits back yet another card deck. If the location identified by the pointer is within cellular telephone 1 00, 
the client process simply retrieves the deck. In either case, fax form 210 (Fig. 2G), that is an entry card, is displayed 
on display screen 105 by cellular telephone 100. This example demonstrates the information accessed by the client 
process can be located in any number of locations. The resource locator associated with the fax key identifies the 
appropriate location. 

10 [0096] When fax form 210 is displayed, the user enters the facsimile machine telephone number at ABC Designs, 
as shown in Figure 2H, using the cellular telephone keypad. In this embodiment, the telephone number is automatically 
formatted by the client process. After the telephone number is entered, the client process appends the telephone 
number to a resource locator and transmits the information to server computer 121 . 

[0097] When server computer 121 receives the information, server computer 121 executes a common gateway in- 

15 terface application (CGI) pointed to by the resource locator. The CGI application grabs the necessary information and 
transmits the information via e-mail to a fax gateway. The fax gateway, upon receipt of the e-mail, converts the infor- 
mation to a fax and sends the information to the specified telephone number. Thus, cellular telephone 100 requires 
neither a printer connection nor a print driver, but yet can print using the facsimile machine at ABC Designs. 
[0098] As illustrated in this example, cellular telephone 100 transmitted a request for a particular purchase order, 

20 and scheduled transmission of data responsive to the request to a local machine capable of printing the data. Thus, 
the processes of this invention, as described more completely below, in cellular telephone 100 in combination with 
data capable cellular telephone network 1 1 0 and server computer 1 21 permit cellular telephone 1 00 to effectively utilize 
an application on server computer 121 on network 120 even though cellular telephone 100 utilizes only a microcontroller 
found in telephone 100 and does not required a separate computer module as in the prior art. 

25 [0099] In addition, the client process using the information transmitted from server computer 121, i.e, the cards, 
generates a wide-variety of user interfaces as illustrated in Figures 2Ato 2H. The particular configuration of the various 
user interfaces is defined by the cards transmitted in a card deck. Consequently, the user interface is not fixed to one 
particular format such as an E-mail type format, but rather the format is variable and can be redefined by each card 
that is interpreted by the client process. Also, in general, the user interface for one application on a server computer 

30 is independent from the user interface for another application on that server computer. 

[0100] Specifically, the application accessed on server computer 121 generates the card deck and so in turn defines 
each of the various user interfaces. Each user interface permits the user to identify a particular selection. Each particular 
selection could result in generation of a different user interface with different selections. Thus, the user interfaces are 
limited only by the applications accessible to the two-way data communication device. 

35 [0101] As shown below, a wide variety of applications can be provided on a server computer. Despite the robustness 
of the client module in interpreting a wide variety of application, typically, the client process is lightweight and thus 
requires only lightweight resources, e.g., 60 Kbytes of read-only memory (ROM) for the client module, 10 Kbytes of 
random access memory (F5AM), and less than one million instructions per second (MIPS) of processing power. Since 
the client process needs only these lightweight resources in a two-way data communication device, the client can use 

40 existing resources in such a device and therefore does not add to the cost of the two-way data communication device 
such as data capable cellular telephone 100. 

[0102] In another embodiment, the user can configure cellular telephone 100 to access server computer 131 on 
corporate local area network 130. In response to the access by the user, computer 131 transmits a home card (not 
shown) to cellular telephone 100 which in turn generates a home screen display on display screen 105. 

45 [0103] When the user selects personal information on the home screen display or on a subsequent screen display 
associated with the home card, a message including a resource locator for a personal information deck is transmitted 
from cellular telephone 100 to computer 131. In response to the message, computer 131 transmits a card deck that 
includes a display card and a choice card to cellular telephone 100. In these examples, the card deck is described as 
including one of three cards, a display card, a choice card, and an entry card. However, these examples are illustrative 

so only, and are not intended to limit the invention to those particular embodiments of cards. In view of this disclosure, 
those skilled in the art will be able to form combinations of these types of cards and define other types of cards, if such 
cards are appropriate for the particular application. 

[0104] The client process in cellular telephone 100 interprets the display card that includes image and text data and 
generates screen display 300 on display screen 105 (Fig. 3A). Screen display 300 includes a home key 301, and an 
55 info key 302. When the user selects home key 301 , the user is returned to the home screen. Info key 302 functions in 
a manner similar to that described above for info key 205. 

[0105] When the user presses a predetermined key, the client process interprets the choice card and a second screen 
display 304 (Fig. 3B) is driven on display screen 105. Screen display 304 is a menu of the personal information that 
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is stored on server computer 131 for use by the user of cellular telephone 100. Multi-display screen card indicator 203, 
e.g., the hand with a finger pointing down, illustrates to the user that the list has additional items that appear on the 
next screen display. Screen display 304 also indicates the number of E-mail messages, faxes, and voice messages 
waiting for the user. 

s [0106] The user scrolls the screen display line by line until screen display 305 is on display screen 105. Initially, the 
fourth item in the menu is not highlighted. In this example, the user presses the four key on the keypad of cellular 
telephone 100 to view the user's schedule. In response to the key press, the client module in cellular telephone 100 
transmits a message, including a resource locator associated with the menu item selected by pressing the four key, to 
server computer 131 using data capable cellular telephone network 110 and corporate local area network 130. 

10 [0107] In response to the message, server computer 131 executes the application identified in the resource locator. 
Upon completion of the execution, server computer 131 transmits, over corporate local area network 130 and data 
capable cellular telephone network 1 1 0 to cellular telephone 1 00, a card deck that includes a choice card that describes 
the user's schedule for that day. 

[0108] In this embodiment, when server computer 131 completes the transmission, server computer 131 has com- 
15 pleted the response to the message and has transmitted all necessary information to cellular telephone 1 00. Therefore, 
server computer 131 does not retain any state information concerning the transmitted information and so is referred 
to as a stateless server computer 1 31 . In this embodiment, the client process can only request a card deck. However, 
as demonstrated herein, card decks and the two-way interactive data communication system of this invention provide 
the user with a new level of capability. 
20 [0109] When cellular telephone 100 receives the card deck, the client process in cellular telephone 100 interprets 
the choice card and drives screen display 306 (Fig. 3D) on display screen 105. Initially, the first item in the menu of 
screen display 306 is not highlighted. When the user depresses the one key on the keypad of cellular telephone 100, 
cellular telephone 100 highlights the first item in the menu. Cellular telephone 100 generates screen display 308 (Fig. 
3E) upon the user subsequently depressing a predetermined key. Screen display 308 includes a schedule key 309, 
25 that when selected returns the user to screen display 306 (Fig. 3D). Screen display 308 also includes a more detailed 
description of the 10:00 a.m. meeting. 

[0110] While screen display 308 is active, if the user depresses a predetermined key, the user is presented with the 
options in screen display 310 (Fig. 3F). Initially, item two in screen display 310 is not highlighted. 
[0111] In this example, the user depresses key two on the keypad of cellular telephone 100 and so cellular telephone 
30 100 sends a message including a resource locator to server computer 131 to send an E-mail message to Bill Smith 
confirming the meeting at 10:00 a.m. When server computer 131 executes the application addressed by the resource 
locator, an E-mail message is sent. 

[0112] In another example, the user of cellular telephone 100 connects to Internet service provider computer 141 on 
Internet 140 using data capable cellular telephone network 110. Upon connection of cellular telephone 100, service 
35 provider 141 transmits to cellular telephone 100 a card deck to generate Figures 4A to 4C. 

[0113] The client process in cellular telephone 100 interprets the first card in the card deck from computer 141 and 
generates screen display 400 (Fig. 4A). When the user presses a predetermined key, cellular telephone 100 displays 
screen display 401 (Fig. 4B). Screen display 401 provides the user with a series of choices that group services alpha- 
betically. 

40 [0114] When the user depresses the seven key on the keypad of cellular telephone 100, cellular telephone 100 
displays a list of the services that have letters P, R, or S as the first letter in the service name. In this embodiment, 
screen displays 401 and 402 are a single card, e.g., a single screen. Each of the various services associated with a 
key has an index and when a particular choice is made by the user, the choice defines an index. The client process 
then displays all of the services with the index that corresponds to the index defined by the user's choice. 

45 [0115] In screen display 402, the user is given a series of choices of services that are available to the user under 
tab seven. Initially, item three in screen display 402 is not highlighted. In this example, the user depresses the three 
key on the keypad of cellular telephone 100 to select the stock quotes and item three in screen display 402 is highlighted. 
[0116] In response to this selection, cellular telephone 100 transmits a request for a stock quote, i.e, a message 
including a resource locator, over cellular telephone network 100 and internet 140 to service provider 141 . In response 

so to the request, service provider computer 141 executes the application addressed by the resource locator. The appli- 
cation retrieves a card deck that, in turn is transmitted to cellular telephone 100. The card deck includes a display card 
and an entry card. 

[0117] Upon receiving the card deck, the client process in cellular telephone 100 interprets the display card and 
generates screen display 403 (Fig. 4D). When the user depresses a predetermined key, entry screen display 406 (Fig. 
55 4E) is generated on display screen 105 of cellular telephone 100. 

[0118] Initially, the box with letters SUNW in screen display 406 is empty. The letters SUNW are entered in the box 
by the user to indicate the ticker symbol of the stock for which the user wants information. After the user has entered 
the stock ticker symbol, the user presses the predetermined key to indicate that the entry is complete. 
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[0119] In response to the entry by the user, the client module appends the stock ticker symbol to the resource locator 
and transmits the resource locator to service provider computer 141 which, in turn, executes an application addressed 
by the resource locator to retrieve the latest stock market information for the stock ticker symbol. Service provider 141 
uses the retrieved information to generate a card deck that contains the information and then transmits the card deck 

s to cellular telephone 100. 

[0120] The client process in cellular telephone 100 interprets the first card in the deck and generates screen display 
409 (Fig. 4F). For convenience, the Figures 4F to 41 are grouped together and separated by a dotted line. However, 
at any given time, in this embodiment, display screen 105 can display any four adjacent lines and so the grouping of 
lines in Figures 4F to 41 is for convenience only to demonstrate the level of information that can be retrieved and 

10 displayed by the client process. The use of a four line display screen is illustrative only. The client process can work 
with any size display screen, even a one line display screen. However, a multi-line display screen is preferred. 
[0121] In the Figures discussed above, the display screen is a pixel display and so can display images. In another 
embodiment, the display screen only displays text and is smaller in size. For such an embodiment, the various entries 
are abbreviated and only text is displayed, but the general operation is identical to that just described. Also, the various 

15 computer networks can be interlinked so that a user with access to one computer network can obtain information on 
another computer network. Moreover, the embodiments described above are merely illustrative. One important aspect 
of this invention is that cellular telephone 100 can interact with any type of server application that is configured to 
communicate with and interact with the client process in cellular telephone 100. Thus, the user is no longer limited to 
only a few services offered by a telephone network provider. 

20 [0122] In Figure 1 , the cellular telephone user must address, i.e., connect to, each computer of interest to access 
the different services. Consequently, each computer requires the information necessary to communicate with cellular 
telephone 100. In another embodiment, not illustrated, cellular telephone 100 contacts a single central computer over 
data capable cellular telephone network 110. This computer is connected to each of the other networks illustrated in 
Figure 1 . Consequently, the user of cellular telephone 1 00 sends a message including a resource locator to the central 

25 computer, the central computer processes the message and retrieves the information addressed by the resource locator 
from the appropriate network shown in Figure 1. After the requested information is retrieved, the central computer 
generates a card deck and transmits the card deck to cellular telephone 100. In this embodiment, only one computer 
must be configured to communicate with cellular telephone 100. However, that same computer must be configured to 
communicate with all other computer networks that are of interest to the user of cellular telephone 100. 

30 [0123] Hence, with this invention, the client process on a two-way data communication device can initiate an inter- 
action with a particular server computer. The server computer transmits (i) information to the client process to generate 
a user interface, and (ii) a resource locator for each possible selection by the user from the user interface. The resource 
locators can address applications on the server computer, applications on over server computers, or an application on 
the server computer that in turn accesses other server computers. Consequently, the user of a two-way data commu- 

35 nication device is limited only by the applications provided on the server computers. 

[0124] Further, the user can be provided new and/or updated capabilities by modifying the applications on the server 
computers. There is no requirement that the client process be changed for a new or updated application. The client 
process must only interpret the information received from an application and transmit a message for additional infor- 
mation. These operations are unaffected by a new or updated application. Consequently, as noted above, this invention 

40 does not require distribution of application updates or new applications to the end user of the two-way data communi- 
cation device. 

[0125] Figure 5 is an illustration of another embodiment of airnet network 150. In this embodiment, the messages 
from a two-way data communication device, e.g., devices 1 00 and 101 are directed to an airnet network translator 500. 
Airnet network translator 500 and a particular two-way data communication device, e.g., any one of devices 100 and 
45 101 communicate using the protocol for point-to-point communication on the particular network linking airnet network 
translator 500 and that two-way data communication device. For example, if data capable cellular telephone network 
1 1 0 is a cellular digital packet data network, either the transmission control protocol (TCP) or the user datagram protocol 
(UDP) can be used. 

[0126] Airnet network translator 500 transfers data between the two-way data communication device and the selected 
so computer network after translator 500 validates the communication path, as explained more completely below, and 
encrypts the message transferred to the computer network if necessary. In addition, airnet network translator 500 
collects transaction and billing information concerning the communication between the two-way data communication 
device and the designated computer network. Specifically, airnet network translator 500 provides access control for 
paying services and a logging mechanism for billing. Airnet network translator 500 can also provide a directory service 
55 to users. 

[0127] Figure 6 is a block diagram of a typical GSM digital cellular telephone. Each of the hardware components in 
cellular telephone 600 is known to those skilled in the art and so the hardware components are not described in detail 
herein. The compiled and linked processes are stored in ROM 601 as a client module 602 and support modules 603. 
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Upon activation of a predetermined key sequence utilizing the keypad, physical layer processor 610, that is sometimes 
referred to herein as a microcontroller, initiates a client process using client module 602 in ROM 601. 
[0128] In this embodiment, client module 602 includes a plurality of manager modules, as explained more completely 
below. The particular manager modules utilized is determined by the characteristics of the particular cellular telephone 

s 100 in which client module 602 is implemented. Client module 602 must include manager modules to interface with 
modules that control the particular hardware in cellular telephone 100, a manager module to interface with the particular 
cellular telephone network protocol used by cellular telephone 100, and a manager module to interpret the card decks 
received. Therefore, the particular manager modules described herein are only illustrative of the principles of this 
invention and are not intended to limit the invention to the specific modules described more completely below. 

10 [0129] In this embodiment, the client process controls the operations of a plurality of cellular telephone dependent 
support processes that are stored in ROM 601 such as a display module, a keypad module, and a network and terminal 
control module, that were referred to above collectively as support modules 603. The combination of the client process, 
display process, keypad process, and network and terminal control process are considered foreground tasks by the 
microkernel in cellular telephone 600. Also, herein module and process are used interchangeably, but those skilled in 

15 the art will appreciate that the module is the computer software as stored in a memory, preferably, a ROM, of cellular 
telephone 600 and the corresponding process is the execution of the module by the microcontroller in cellular telephone 
600. Again, note that this invention does not require a separate processor and instead can utilize the processing power 
that already exists in cellular telephone 600, because as described above, the client process is so lightweight. 
[0130] The user interface for cellular telephone 600 determines the version of the user interface manager module 

20 that is stored in ROM 601 . In one embodiment, the parameters used to define the user interface level are the display 
resolution, the pixel access of the display, and the support of soft keys. One definition of the user interface levels is 
given in Table 1 . 



TABLE 1 



USER INTERFACE LEVEL DEFINITIONS 


Level 1 
Level 2 
Level 3 


Text only; 1 or more lines; 12 to 15 characters per line; and no soft keys. 
Text only; 4 or more lines; 20 to 25 characters per line; and soft keys. 
Pixel access; 1 50 by 75 pixels or larger; and soft keys. 



[0131] The user interface manager module presents data to the display module which in turn drives display screen 
605; and captures data entered by the user on display screen 605. In response to this information, the client process 
prepares a message for transmission by a network manager module. 

[0132] To more completely explain the operations performed over airnet network 150, Figure 7 is a block diagram 
that illustrates the various components in one embodiment of this invention of cellular telephone 700. Those skilled in 
the art will appreciate that cellular telephone 700 includes circuitry and software similar to that illustrated in cellular 
telephone 600 for voice and data operations supported by cellular telephone 700 in addition to the modules for operation 
on airnet network 750. Similarly, server computer 743 includes other software and hardware that is known to those 
skilled in the art and so is not illustrated in Figure 7 for clarity. 

[0133] In this embodiment, client module 702 in digital cellular telephone 700, that is executing on the microcontroller 
of telephone 700, communicates with server computer 743 over cellular digital packet data (CDPD) network 710. 
Cellular digital packet data network 710 is used to illustrate one embodiment of this invention on one two-way data 
communication network. The principles of this invention can be used with a wide variety of two-way data communication 
networks. For example other two-way data communication networks for cellular telephones that may be used include 
TDMA, CDMA, and GSM circuit switched data networks; and the AMPS analog cellular network with a modem. Similarly, 
for two-way pagers, two-way data communication networks include PACT, or other priority two-way paging networks 
with data transport capability. 

[0134] Prior to considering the operation of this configuration of airnet network 750 in more detail, another aspect of 
this invention is required. Specifically, a technique is required for conveying instructions from digital cellular telephone 
700 to a server application on server computer 743, and conversely. 

[0135] A telephone interaction description language (PIDL) is defined for use by service developers. A terminal in- 
teraction language (TIL) is a distillation of the telephone interaction description language and describes the same 
interaction to digital cellular telephone 700 as the telephone interaction description language describes to computer 
743. 

[0136] With the exceptions described more completely below, a process in the terminal interaction language is a 
compressed version of the same process written in the telephone interaction description language. The terminal inter- 
action language allows easy parsing on the two-way data communication device, which in turn makes the client smaller 



14 



EP 0 779 759 B1 



than a client for the telephone interaction description language that is readable by humans, but is not optimized for 
parsing by a machine. 

[0137] The compression from the telephone interaction description language to the terminal interaction description 
language is done typically at run time because some cards are computed cards and so cannot be precompiled. A wide 
s variety of techniques can be used to convert the telephone interaction description language to terminal interaction 
language. The important aspect is that, if bandwidth across the cellular telephone network is limited, a compressed 
form of the telephone interaction description language is used. 

[0138] Preferably, each data type is compressed to facilitate optimal transfer over the two-way data communication 
network. For example, the verbs in the telephone interaction description language are compressed using a binary 
10 tokenization. Graphics are compressed using run length limited compression and text is compressed using any one 
of the well-known techniques for text compression. While compression of the telephone interaction description lan- 
guage is not required to implement this invention, compression makes the invention more efficient by utilizing the 
bandwidth of the network more effectively. 

[0139] Instructions in the telephone interaction description language and in the terminal interaction language are 
15 grouped into a deck and a card. Each deck includes one or more cards. A card includes the information, i.e., a set of 
telephone interaction description language, required to generate a screen. As indicated above, a screen can be larger 
than the number of lines in a display screen. Other equivalent terms for a card include a page and an atomic interaction. 
Thus, a card deck is simply a group of screens. The number of cards in a card deck is selected to facilitate efficient 
use of the resources in the two-way data communication device and in the airnet network. 
20 [0140] For simplicity, in this embodiment, each card is a single operation. Herein, an operation is defined as a related 
set of actions such that the user does not encounter an unanticipated delay in moving from one action to the next, i. 
e, the user does not have to wait for client module 702 to retrieve another card deck from computer 743. Also, a deck 
may include definitions of soft keys that stay in force while the deck is active, i.e, being executed by the cellular telephone 
microcontroller. 

25 [0141] Computer 743 may contain stored static telephone interaction description language decks. Computer 743 
also generates telephone interaction description language decks in response to data from, or choices made by, the 
user of cellular telephone 700. 

[0142] In the embodiment shown in Figure 7, computer 743 converts a telephone interaction description language 
deck to a terminal interaction language deck, that in turn is transmitted to cellular telephone 700. The terminal interaction 

30 language is designed so that decks can be stored unaltered in memory 71 6 of cellular telephone 700 and referenced 
directly with little or no parsing. While telephone interaction description language decks on computer 743 may contain 
references to images, a terminal interaction language deck contains the images at the end of the deck. Thus, if a 
particular two-way data communication device does not support display of images, the images are easily stripped from 
the terminal interaction language deck before the deck is transmitted to that particular two-way data communication 

35 device. 

[0143] As indicated above, each interaction with the user of cellular telephone 700 is described by a deck or a series 
of decks. Logically, the user retrieves a terminal interaction language deck stored in a memory 716 of cellular telephone 
700 after receipt from computer 743 over CDPD network 710. The user reviews the information displayed by cards in 
the deck and makes choices and/or enters requested information and then requests another deck, as described above 

40 with respect to Figures 2A to 2H, for example. 

[0144] When the user receives a deck, the first card of information is displayed on display screen 705. Typically, as 
shown above, the first card is text, an image, or a combination of an image and text. After the user has reviewed the 
first card, the user hits a NEXT key to view the next card in the deck. Similarly, a user can return to a previous card in 
the deck by using a PREV key. Thus, using the NEXT and PREV keys, the user can navigate back and forth through 

45 the deck. Within a card, the user uses a scroll key or keys to move the portion of the card displayed up and down. This 
description of a particular method used to navigate through a deck and within a card is not intended to limit the invention 
to this particular method. In view of this disclosure, those skilled in the art will be able to use a wide variety of ways to 
navigate through a deck and within a card. 

[0145] Cards, in this embodiment, are one of three types, a display card, a choice card, and an entry card. Inde- 
50 pendent of the type of card, the card can contain text and images. In addition, the invention is not limited to these three 
particular types of cards. The definition of the three particular types of cards is used to facilitate a description of the 
invention and to assist the developer's in organizing applications. 

[0146] A display card gives information to the user to read. The display content can include any one of, or any 
combination of text, an image, and a soft key. The soft key is in effect only while the display card is active. 
55 [0147] A choice card displays a list of choices for the user. The choices are automatically presented in a format 
specified on the choice card. See Appendix I, which is a part of the present disclosure and is incorporated herein by 
reference in its entirety. As explained above, the user makes a choice by depressing the key corresponding to the 
choice. 
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[0148] An entry card is used to obtain input data from the user. An entry card displays one or more entry lines. 
Typically, each entry line includes a display followed by an entry line. The entry line, in this embodiment, can be for 
either numeric or text data. 

[0149] In this embodiment, choice and entry cards prevent the user from moving to the next card until the user has 
s entered the requested information. When the user reaches the last card in a deck and hits the NEXT key, a request 
for a new deck is initiated. The deck requested is determined by either the deck that the user has completed, or by the 
choices made by the user. Also, when the deck is completed, the choices and/or data entered by the user typically are 
transmitted along with the request for the new deck to computer 743. 

[0150] Appendix I is one embodiment of a syntax for the telephone interaction description language and the terminal 
10 interaction language used with this invention. In one embodiment, the telephone interaction description language is 
described using a subset of the standard generalized markup language. Only a subset of the standard generalized 
markup language is utilized so that telephone interaction description language parsers also can be written easily using 
simple tools like lex and yacc. 

[0151] Returning to operation over airnet network 750, cellular telephone 700 includes a display module 712, a 
15 keyboard module 711 , a client module 702, and a UDP interface module 714. In this embodiment, module 702 is stored 
in a non-volatile memory (not shown) of telephone 700 and is executed by the microcontroller (not shown) in telephone 
700. Modules 711, 712, and 714 operate under the control of client module 702. 

[0152] Client module 702 includes instructions that direct the microcontroller in cellular telephone 700 to perform the 
operations described more completely below with respect to Figures 8A to 8D. The operations include sending uniform 
20 resource locator (URL) requests to HyperText Transfer Protocol (HTTP) server 749, parsing and displaying a TIL deck 
or decks returned by HTTP server 749, and generating new URLs based on the user's key presses. For a description 
of HTTP server software and platforms that can run the HTTP server software, see, for example, Ian S. Graham, The 
HTML Sourcebook , John Wiley & Sons, Inc., New York, Chapt. 8, (1995). 

[0153] User datagram protocol (UDP) interface module 714 couples CDPD network 710 to client module 702, and 
25 allows client module 702 to communicate using UDP over CDPD network 710. The user datagram protocol is well 
known to those skilled in the art and is documented extensively. UDP interface module 714 supports transmission of 
simple stand-alone messages between the connection partners. 

[0154] Display module 712 is a display driver that couples client module 702 to display screen 705 and so allows 
client module 702 to specify the information presented on display screen 705. The user interface manager module 

30 within client module 702 converts the display information in a card to instructions for display module 704 which in turn 
provides signals that drive the hardware that controls the operation of display screen 705. For example, if the TIL deck 
includes an image, the user interface manager module determines whether the active card calls for display of the 
image. If the active card directs the user interface manager module to display the image, the user interface manager 
module passes the image in memory 71 6 to display module 712, which in turn displays the image on display screen 705. 

35 [0155] Keyboard module 705 couples keypad 715 to client module 702, and stores data representing keys pressed 
by the user on physical keypad 715 in memory 716. Keyboard module 705 notifies client module 702 when the user 
has pressed a key. 

[0156] When client module 702 is notified of a key press, the user interface manager module within client module 
702 passes information about the key press to display module 712 that in turn displays the appropriate character on 

40 display screen 705, if an entry card is active. If the user interface manager module determines that a choice card is 
active, and the key press corresponds to one of the choices, the user interface manager module sends instructions to 
display module 712 that result in the choice being identified for the user, e.g., highlighted as described above. 
[0157] In addition to HTTP server 749, host computer 743 includes a UDP interface module 748, CGI programs 761 
stored in a memory 755 of host computer 743, and TIL decks 760 stored in memory 755. 

45 [0158] HTTP server 749 uses UDP interface module 748 to send data to and receive data from CDPD network 710. 
TIL decks 760 are TIL decks that can be accessed by HTTP server 749. Staticfiles containing PIDL decks are converted 
to TIL decks only once on HTTP server 749. CGI programs 761 are common gateway interface programs that produce 
PIDL decks that are used by HTTP server 749 to produce TIL decks that in turn are transmitted via UDP interface 
modules 748 and 714 and cellular telephone network 710 to client module 702. In this embodiment, the services 

50 available over airnet network 750 are applications accessible by HTTP server 749 on Internet 140 for which a service 
developer has written a PIDL deck, or a CGI script that in turn generates a PIDL deck, and is stored on computer 743. 
[0159] The architecture in Figure 7 demonstrates some important aspects of this invention. First, the applications, 
the PIDL decks and CGI scripts in this embodiment, are independent of the particular two-way data communication 
network. For HTTP server 749 to communicate over a different two-way data communication network that does not 

55 support UDP, only UDP interface module 748 must be changed. The applications are unaffected by such a change. 
[0160] Second, the applications on HTTP server 749 are independent of the two-way data communication device 
with which HTTP server 749 is interacting. An application on HTTP server 749 can communicate with any two-way 
data communication device that includes the appropriate client and a module to transmit and receive data over the 
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two-way data communication network. These two facts mean that an investment in developing an application is insu- 
lated from either advances in two-way data communication devices, or advances in two-way data communication 
network technology. 

[0161] Figures 8A to 8D are a process flow diagram for one embodiment of this invention. Initially, when the user 

s initiates communication over airnet network 750, client module 702 initializes a work space in memory 716 of cellular 
telephone 700 and then, in get home URL process 801, stores a URL in the work space. With this invention, in one 
embodiment, each cellular telephone that utilizes the airnet network has a home URL stored in a non-volatile memory 
that is used to retrieve a home card deck for the cellular telephone. In another embodiment, the cellular telephone 
obtains the home URL from server 749. Thus, in get home URL process 801 , client module 702 obtains the home URL. 

10 Herein, a URL is an example of a specific embodiment of a resource locator. 

[0162] For example, in get home URL process 801, client module 702 obtains a home URL, such as 

http://www.libris.com/airnet/home.cgi 
and stores the home URL in the work space. The portion of the home URL, http:/www.libris.com, identifies a particular 
HTTP server, i.e, server 749, on the world-wide web. The portion of the URL, /airnet/home.cgi, specifies a particular 

15 common gateway interface program within CGI programs 761. The use of a URL pointing to a server on the world- 
wide web is illustrative only is not intended to limit the invention to applications on the world-wide web. In general, 
cellular telephone 700 obtains an identifier, i.e, a resource locator, of a home application on a home server that is 
executed by the server when the cellular telephone initially becomes active on airnet network 750, and stores the 
resource locator in the work space. 

20 [0163] Next in create HTTP request process 802, client module 702 converts the URL in the work space to a HTTP 
request. For example, for the above URL, create HTTP request process 802 generates a method field, such as 

GET /airnet/home.cgi HTTP/1 .0 
The GET method is part of HTTP. Thus, the format for the GET method is known to those skilled in the art. Also, this 
particular form of the method is used because a specific server connection is established by cellular telephone 700 

25 and so identification of the server is unnecessary. Nevertheless, briefly, this command instructs server 749 to execute 
application home.cgi and execution of application home.cgi in turn results in generation of a home deck and a subse- 
quent transmission of the home deck to cellular telephone 700. HTTP/1.0 specifies the HTTP version used by client 
module 702 in cellular telephone 700. 

[0164] In addition to the method field, client module 702 in process 802 could also generate appropriate HTTP request 
30 fields to pass information to server 749 about the capabilities of client module 702. The request fields can include 
information such as lists of the MIME content-types acceptable to the client; lists of data encoding types acceptable 
to the client; user authentication and encryption scheme information for the server; the length in bytes of the message 
being sent to the server; and the Internet mail address of the user accessing the server. This list of information is 
illustrative only and is not intended to limit the invention to the particular request fields described herein. Any request 
35 field defined by HTTP can be utilized by client module 702. However, in this embodiment, the defaults are utilized and 
so no HTTP request fields are generated. 

[0165] Typical HTTP methods that can be generated in HTTP request process 802 are a GET method for requesting 
either a TIL deck from server 749, or execution of a common gateway interface program on server 749; and a GET 
method request to a common gateway interface program with data, e.g., a query string appended to the URL. In either 
40 case, a URL is transmitted to server 749 within the particular message. After create HTTP request process 802 is 
complete, client process transfers to transmit request process 804. 

[0166] However, if the transmission control protocol is used instead of UDP, client module 702 would access a TCP 
module in establish server connection process 803 that replaced UDP module 714. Since, in this embodiment, UDP 
is used, establish connection process 803 is enclosed by a dashed line in Figure 8A to indicate that this process is 

45 unnecessary when using UDP. 

[0167] In establish server connection process 803, a virtual connection would be made over CDPD network 710 
between TCP interface module 714 and a TCP interface module in HTTP server 749 so that data could be transmitted 
between cellular telephone 700 and computer 743 using TCP, e.g., buffers to support data exchange are defined. The 
establishment of a TCP connection is well-known and so is not described further. 

so [0168] In Figure 8A, a dashed line connects establish server connection process 803 with establish client connection 
process 860, that is also dashed, that is performed by HTTP server 749. This indicates that both client module 702 
and server 749 are required to complete process 803. 

[0169] When the TCP virtual connection is established, client module 702 transfers processing from establish server 
connection process 803 to transmit request process 804. Similarly, server 749 transfers to request received check 861 , 
55 in which server 749 waits until a request is received. Establish client connection process 860 is not needed for UDP 
and so HTTP server 749 initiates processing in request received check process 861. Process 860 is enclosed within 
a dashed line box to indicate that the process is used only for TCP. 

[0170] In transmit request process 804, the HTTP request is sent from the work area in telephone 700 to HTTP 
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server 749. Again, a dashed line connects process 804 of client module 702 to request received check 861 that is 
performed by HTTP server 749 to indicate that the check is dependent upon information from client module 702. When 
the transmission of the request is complete, client module 702 transfers to response received check 806. 
[0171] Upon receipt and storage of the HTTP request, request received check 861 transfers to service request proc- 

s ess 862 in which HTTP server 749 initiates service of the received request. In service request process 862, if the HTTP 
request only seeks transfer of a static deck, HTTP server 749 retrieves the requested static deck from TIL decks 760. 
Conversely, if the request requires server 749 to obtain data from the Internet or to append data to a particular file, 
server 749 launches the common gateway interface application addressed in the request, and passes the data in the 
HTTP request to this application for further processing. 

10 [0172] For example, if the user of cellular telephone 700 requested a fax as in Figure 2F, the HTTP request identifies 
a common gateway interface application in CGI programs 761 that accepts as input data the telephone number and 
grabs the information to be faxed. The CGI application generates an e-mail transmission to the fax gateway. Similarly, 
for a stock quote, server 749, in response to the HTTP request, launches a common gateway interface application that 
sends out a stock query over Internet 140 to a stock quote service provider using the ticker tape symbol passed as 

15 input data by server 749 to the common gateway interface application. When the response to the stock query is re- 
ceived, the common gateway interface application builds a PIDL deck that includes the data in the response to the 
stock query. 

[0173] Upon completion of servicing the request, HTTP server 749 converts the PIDL deck to a TIL deck and returns 
the TIL deck to client module 702 using UDP in transfer response process 863, that is connected by a dotted line to 
20 response received check 806 in client module 702. As the TIL deck is transferred, client module 702 stores the deck 
in memory 716. 

[0174] After the TIL deck is transferred, HTTP server 749 closes the process for responding to the message from 
cellular telephone 700. All the information needed by client module 702 to generate a user interface on display screen 
705 and for responding to any selection or data entry presented in the user interface is included in the TIL deck. 
25 Consequently, client module 702 only has to interpret the TIL deck and interpret the user input to transmit the next 
message to HTTP server 749. The state for the HTTP server is defined in the next message. Consequently, HTTP 
server 749 is stateless because HTTP server 749 does not retain state information concerning a response to a message 
after the message is transmitted. 

[0175] However, in another embodiment (not shown), a server could retain state information concerning each inter- 
30 action with a client module. For example, if the server transmitted a choice card to the client module, the server would 
retain state information indicating that a choice was pending from the client module. In this embodiment, when the user 
makes a choice, e.g., depresses key two to indicate choice two, the choice is transmitted to the server which in turn 
accesses the URL associated with choice two. If this URL addresses another application, the server executes that 
application. Thus, in this embodiment, the server retains state information concerning each interaction with a client 
35 module. In view of this disclosure, those skilled in the art can implement the principles of this invention utilizing a server 
that retains state information when such a client/server combination is advantageous. 

[0176] Returning to the present embodiment, when the TIL deck is received, client module 702 leaves response 
received check process 806 and transfers to process first card 808. However, if TCP is used instead of UDP, client 
module 702 upon leaving check 806 would close the virtual TCP connection in transmission completed process 807. 
40 Upon closing the virtual TCP connection, processing would transfer to process first card 808. Again, transmission 
complete process 807 is enclosed within a dashed line box to indicate that process 807 is used only with TCP. 
[0177] In process first card 808, client module 702 parses the TIL deck and interprets the first card. Processing 
transfers from process first card 808 to generate display process 809. 

[0178] In generate display process 809, client module 702 passes the data to be displayed in the first card to display 
45 module 712. Display module 712, in response to the data, drives the text and images in the data on display screen 
705. Generate display process 809 transfers processing to key press check 820 through node 813. In Figures 8A to 
8D, any circular node with the same alphanumeric character and reference numeral is the same node. The circular 
nodes are used to establish connections between the various processes in the method of Figures 8A to 8D without 
cluttering the figures with a number of connection lines. 
so [0179] Client module 702 waits in key press check 820 for the user to press a key on keypad 715 of cellular telephone 
700. In this embodiment, cellular telephone 700 is assumed to have the capability to support two soft keys, a scroll- 
up key, a scroll-down key, a previous key, a next key, and keys zero to 9 that are configured in the standard telephone 
keypad configuration. In view of the following disclosure, if one or more of these keys are not present, one of skill in 
the art can alter the method for the particular configuration of the cellular telephone keypad, or other two-way data 
55 communication device keypad. For example, if the cellular telephone included a home key, the key press processing 
described more completely below would include a check that detected when the home key was pressed and would in 
turn transfer to get home URL process 801. 

[0180] Briefly, the processes in Figures 8B to 8C, identify the key pressed by the user, identify the action required, 
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and then transfer to a process that implements the action required. Specifically, when a key on the keypad is pressed, 
keypad module 711 stores an identifier for the key in work memory 716 and notifies client module 702 of the key press. 
Upon receipt of the notification from keypad module 711, client module 702 reads the storage location in work memory 
716 to determine the key pressed and transfers processing from key press check 820 to scroll key check 821 . 

s [0181] In scroll key check 821 , client module 702 determines whether the user pressed either of the scroll keys. If a 
scroll key was pressed, processing transfers to adjust display process 822 and otherwise to display card check 823. 
[0182] In adjust display process 822, client module 702 determines which of the scroll-up or scroll-down keys was 
pressed. Client module 702 then sends information to display module 712 so that the current display is either scrolled- 
up one line or scrolled- down one line. If the scroll key would move the display beyond a boundary of the current card, 

10 the scroll key press is ignored in adjust display process 822. 

[0183] In response to the information from client module 702, display module 712 adjusts the screen display on 
display screen 705. Client module 702 transfers processing from adjust display process 822 to key press check 820 
through node 813. 

[0184] If a scroll key was not pressed, processing is passed through scroll key check 821 to display card check 823. 
15 Client module 702 takes action that depends on the particular type of card that is currently being displayed on display 
screen 705. If the current card is a display card, client module 702 passes through display card check 823 to soft key 
check 828, and otherwise transfers to choice card check 824. 

[0185] Assuming for the moment that the current card is not a display card, choice card check 824 determines whether 
the current card is a choice card. If the current card is a choice card, client module 702 passes through choice card 

20 check 824 to choice key check 826, and otherwise transfers to data key check 826. 

[0186] Assuming for the moment that the current card is neither a display card nor a choice card, the current card 
must be an entry card, because in this embodiment only three card types are defined. Thus, client module 702 does 
not check for an entry card. Rather, data key check 826 determines whether a valid data key was pressed. In this 
embodiment, the data keys are keys zero to nine on the key pad, and the # key. In other embodiments, other combi- 

25 nations of keys could be defined as data keys. If the pressed key was one of the data keys, data key check 826 transfers 
to process data entry 827 and otherwise transfers to soft key check 828. 

[0187] In process data entry 827, client module 702 knows whether the predictive text entry process is turned-on, 
because one of the parameters on the entry card specifies whether to use the predictive text entry process, as described 
in Appendix I, which is incorporated herein by reference in its entirety. 
30 [0188] If the predictive text entry process is not turned-on, client module 702 in process data entry 827 enters the 
pressed key value in a text entry buffer in work memory 716 at the appropriate location. Also, client module 702 sends 
information to display module 712 so the value of the pressed key is displayed in the appropriate location on display 
screen 705 by display module 712. 

[0189] If the predictive text entry process is turned-on, client module 702 uses the novel predictive text entry process 
35 in process data entry 827, as described more completely below with respect to Figures 9, 10A to 10T, and 11, to 
determine the letter to select from the set of letters associated with the pressed key. After the predictive text entry 
process determines the appropriate letter, a value representing the letter is stored at the appropriate location in the 
text buffer in work memory 716. Also, client module 702 sends information to display module 712 so that the letter is 
displayed in the appropriate location on display screen 705. Upon completion of process data entry 827, client module 
40 702 transfers processing through node 81 3 to key press check 820. 

[0190] The previous description assumed that the current card was an entry card, but if the current card is a choice 
card, choice card check 824 transferred to choice key check 826. In generate display process 804 for the choice card, 
each of the choices are labeled according to information on the choice card and some or all of the choices are displayed 
on display screen 705. Thus, choice key check 826 determines whether the pressed key corresponds to one of the 
45 choices. If the pressed key is one of the choices, client module 702, in one embodiment, sends information to display 
module 712 to indicate the selected choice. Client module 702 also transfers from choice key check 826 through node 
831 to store identifier process 850 (Fig. 8D), that is described more completely below. Conversely, if the pressed key 
is not one of the choices, choice key check 826 transfers to soft key check 828. 

[0191] Soft keys can be specified both for a deck as a whole and per card, i.e., a physical key on the keypad is 
50 specified as a soft key as described more completely in Appendix I. Each soft key specification includes an identifier 
that defines the action to be taken when the soft key is pressed. 

[0192] When a soft key is specified for a deck, the soft key remains in effect for the entire deck. However, when a 
soft key is specified for a card, the card soft key specification temporarily overrides the corresponding deck soft key 
specification, i.e., the deck soft key specification for the same physical key as the card soft key specification, while the 
55 card is visible, i.e., displayed on display screen 705. This override is done independently for the two soft keys. Thus, 
soft key check 828 transfers processing to first soft key check 829 if the key pressed is one of the two possible physical 
soft keys. Conversely, soft key check 828 transfers processing to next key check 840 (Fig. 8C), if neither of the two 
possible physical soft keys is pressed by the user. 
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[0193] In first soft key check 829, client module 702 determines whether the pressed key corresponds to the first 
soft key. If the pressed key is the first soft key, check 829 passes the active identifier for the first soft key to store 
identifier process 850 through node 831. Conversely, if the pressed key is not the first soft key, processing transfers 
from check 829 to second soft key check 830. 

s [0194] If the pressed key is the second soft key, check 830 passes the active identifier for the second soft key to 
store identifier process 850 through node 831 . Conversely, if the pressed key is not the second soft key, e.g., a physical 
key that can be defined as a soft key was pressed but neither the current deck nor the current card defines a soft key 
for that physical key, processing transfers from check 830 to key press check 820 through node 813. 
[0195] When pressing transfers to next key check 840, client module 702 determines whether the pressed key was 

10 the next key. If the next key was pressed, processing transfers to display card check 841 and otherwise to previous 
key check 846. 

[0196] If a display card is the current card, the next key is used to move to another card in a deck, or alternatively 
to another deck. Thus, display card check 841 transfers processing to last card check 842 when a display card is the 
current card, and otherwise to entry card check 843. 

15 [0197] Last card check 842 determines whether the current card is the last card in the deck. If the current display 
card is not the last card in the deck, last card check 842 transfers processing to read next card process 845, which in 
turn reads the next card in the deck and transfers through node 812 to generate display process 809. 
[0198] If the current display card is the last card in the deck, the deck includes an identifier that specifies the location 
to transfer to from the last card. This identifier can be a URL to another deck, to a common gateway interface program, 

20 or an address for a card within the current deck, for example. Thus, last card check 842 transfers through node 831 
to store identifier process 850 when the current display card is the last card in the deck. 

[0199] If the current card is not a display card but is an entry card, display card check 841 transfers to entry card 
check 843. In this embodiment, the next key is the predetermined key used to indicate that all the data for an entry on 
an entry card has been entered. Thus, if the current card is an entry card, entry card check 843 transfers processing 

25 to store data process 844. 

[0200] Store data process 844 stores the data entered in at an appropriate location in memory that is specified in 
the current entry card. Typically, the data is combined as an argument with a URL and stored. Upon completion, store 
data process 844 transfers through node 810 to create HTTP request process 802 (Fig. 8A). 
[0201] When the next key is pressed, if the current card is neither a display card nor an entry card, the current card 

30 is a choice card. However, as indicated above, in this embodiment client module 702 requires that the user make a 
choice and does not allow use of the next key. Consequently, if the current card is not an entry card, entry card check 
843 transfers processing through node 813 to key press check 820. 

[0202] The previous discussion assumed that the next key was pressed and so next key check 840 transferred 
processing to display card check 841 . However, if the next key was not pressed, next key check 840 transfers processing 
35 to previous key check 846. If the previous key was pressed, check 846 transfers to first card check 847 and otherwise 
returns processing to key press check 820. 

[0203] First card check 847 determines whether the current card is the first card of a deck. If the current card is not 
the first card, processing transfers from first card check 847 to read previous card 849, which in turn reads the previous 
card and transfers to generate display process 809 through node 813. Conversely, if the current card is the first card, 

40 processing transfers to home deck check 848. 

[0204] If the current card is the first card in the home deck, there is not a previous card and so home deck check 
transfers processing to key press check 820 through node 81 3 and so the previous key press is ignored. If the current 
deck is not the home deck, home deck check 848 retrieves the identifier for the previous deck and transfers through 
node 831 to store identifier process 850. 

45 [0205] Store identifier process 850 is reached through node 831 from several different points. The operations in store 
identifier process 850 are the same irrespective of the particular process that transfers to process 850. In each instance, 
an identifier is passed to store identifier process 850 and process 850 saves the identifier in working memory 716. The 
identifier can be, for example, a pointer to another location in the current card, an address of another card in the current 
deck, a URL to a deck stored in working memory 716, a URL to a TIL deck in TIL decks 760 on computer 743, or 

50 perhaps, a URL to a common gateway interface program in CGI programs 761 on computer 743. Thus, process 800 
checks the stored identifier to determine the action required. 

[0206] Specifically, in identifier to current deck check 851 , client module 702 determines whether the identifier is to 
a card in the current deck. If the identifier points to the current deck, check 851 transfers processing to retrieve data 
process 852 and otherwise to URL to local deck check 853. 
55 [0207] In retrieve data process 852, client module 702 retrieves the information stored at the location indicated by 
the identifier from working memory 716 and processes the information. Retrieve data process 852 transfers through 
node 812 to generate display 809 (Fig. 8A) that was described above. 

[0208] URL to local deck check 853 determines whether the identifier is a URL to a deck that is stored in working 
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memory 716, e.g., cached. If the deck is stored locally, check 853 transfers to retrieve local deck 854 which in turn 
moves the local deck into the storage location for the current deck. Retrieve local deck 854 transfers processing through 
node 811 to process first card 808 (Fig. 8A), that was described above. 

[0209] If the identifier is neither to a location in the current deck, nor to a local deck, the identifier is a URL to an 
s object on computer 743. Thus, in this case, check 853 returns processing to create HTTP request 802 through node 810. 
[0210] Process 800 continues so long as the user continues to enter and process the information provided. In this 
embodiment, process 800 is terminated, for example, either by the user powering-off cellular telephone 700, selecting 
a choice or entry card that discontinues operations of client module 702, or remaining inactive for a time longer than 
a time-out period so that client module 702 shuts itself down. 
10 [0211] To further illustrate the operations in process 800, consider the following example which is returned to client 
module 702 as a TIL deck in response to a HTTP request generated by process 802. For readability, Table 2 presents 
the deck in PIDL. In this example, all of the choices are for applications on the same server. However, in another 
embodiment, each URL could address any desired combination of servers. 

15 TABLE 2 

EXAMPLE OF PIDL CHOICE DECK 

<PIDL> 
<CHOICE> 

<CE URL=http://www.libris.com/airnet/nnn>News 

20 

<CE URL=http://www.libris-com/airnet/www>Weather 
<CE URL=http://www.libris.com/airnet/sss>Sports 
</CHOICE> 
</PIDL> 

25 

[0212] In process first card 808, client module 702 interprets the information in Table 2 and transfers to generate 
display process 809. In generate display process 809, client module 702 sends information to display module 712 so 
that the user is presented with a list of three choices on display screen 705, i.e, a user interface for the choice card is 
generated: 

30 

1. News 

2. Weather 

3. Sports 



35 [0213] Generate display process 809 (Fig. 8A) transfers to key press check 820 (Fig. 8B). When the user presses 
the two key on keypad 715, key press check 820 transfers through check 821 to display card check 823. 
[0214] Since the current card is a choice card, check 823 transfers processing to choice card check 824, which in 
turn transfers to choice key check 826. Since the two key was pressed and that key is a choice key, check 826 transfers 
processing to store identifier process 850 (Fig. 8D). In process 850, client module 702 stores the URL corresponding 

40 to two, i.e, 

URL=http://www.libris.com/airnet/www 
in working memory 716. 

[0215] Since this URL is to an object on computer 743, processing transfers through checks 851 and 853 to create 
HTTP request process 802, which in turn generates the request. When the HTTP request is transmitted to server 749, 
45 as described above with respect to process 804, server 749 in service request process 862 retrieves deck www from 
TIL decks 760. An example of the deck is given in Table 3. Again for readability, the deck in present herein in PIDL. 

TABLE 3 

EXAMPLE OF A SECOND PIDL CHOICE DECK 
50 <PIDL> 

<CHOICE> 

<CE URL=http://www.libris.com/airnet/www-1 >World 
<CE URL=http://www.libris.com/airnet /www-2>National 
<CE URL=http://www.libris.com/airnet/www-3>State 

55 

<CE URL=http://www.libris.com/airnet/www-4>Local 

</CHOICE> 

</PIDL> 
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The deck in Table 3 is transmitted to cellular telephone 700 and stored in memory 716, as described above with respect 
to process 806. The choice card is processed in process 808 and displayed in process 809. As a result of process 
809, the user is presented with a list of choices: 

5 1 . World 

2. National 

3. State 

4. Local. 

10 [0216] When the user makes another selection, the same sequence of processes as described above for the first 
choice card is executed by client module 702, and another URL is stored that points to a program on server 749 that 
retrieves the desired weather information and generates a deck with that information. This deck is transferred to cellular 
telephone 700 and displayed. 

[0217] As described above, if the current card is an entry card and a key is pressed, client process 702 reaches data 
15 key press check 826 (Fig. 8B). If the pressed key is a valid data key, check 826 transfers to process data entry 827. 
[0218] In one embodiment, process data entry 827 uses a novel predictive text entry process for text entry. Recall 
that on a typical telephone keypad, the keys are labeled with both a number and two or three letters. For example, the 
two key is also labeled abc. This leads to some ambiguity when using the telephone keypad to enter text. Is the user 
attempting to enter an a, b, or c when the two key is pressed? 
20 [0219] In one prior art method, two keystrokes were required to enter each letter of text. The first keystroke identified 
the first key and the second key stroke identified the specific letter desired on the first key. For example, to enter the 
letters, the user would first press the seven key that is labeled with letters p, r, and s. Next, the user would press the 
three key to select the letter s. While this method may work well for short sequences that consist of only three or four 
letters, the method does not work well for English text. For example, if the user has already entered th and then presses 
25 the three key that is labeled with letters d, e, and f, almost always the desired next letter is the letter e. Therefore, 
making the user press the two key is an extra and unnecessary step. 

[0220] Client module 702 utilizes a novel predictive text entry process to reduce the number of key strokes required 
to enter text using a telephone keypad, or any similar keypad. Using this process, in most cases a single key stroke 
suffices to enter a single letter. 

30 [0221 ] While this process is described in terms of a telephone keypad, the principles are not limited to only a telephone 
keypad. In general, the process described more completely below, can be extended to any keypad where a single key 
is used to enter two or more letters. Further, the process is not limited to only letters, but rather is applicable to any 
keypad where a single key is used to represent two or more characters. In view of the following disclosure, those skilled 
in the art can use the principles of the predictive text entry process in a wide variety of applications. 

35 [0222] The system for predictive text entry includes a predictive text entry module 901 that in this embodiment is 
included in client module 702, keyboard module 711, and a letter frequency table 902 that is loaded into memory 716, 
when client module 702 is activated. Predictive text entry module 901 is used in process data entry 827 when specified 
by the current entry card. Predictive text entry module 901 performs routine buffer management processes, that are 
known to one of skill in the art and so are not described further to avoid detracting from the process. 

40 [0223] Predictive text entry module 901 stores a letter entry for each letter entered in a text buffer 903 in memory 
716. In this embodiment, letters Q and Z are assigned to the one key and the zero key is used to enter a space, period, 
and comma, i.e., the zero key provides punctuation. However, these assignments are illustrative only, and are not 
intended to limit the invention to this particular embodiment. 

[0224] The first letter entered is placed at the left end of the buffer and each additional letter is placed in the left most 
45 unused space in buffer 903. Thus, the last letter entered in text buffer 903 is the right most character. Letter frequency 
table 902, sometimes referred to as a table of predictive letter entries, is a look-up table where each entry in the look- 
table is addressed by three indices. The first two indices represent the two most recently entered letters in text buffer 
903 and the third index represents the key that was pressed. Each predictive letter entry stored in letter frequency 
table 902 defines which of the letters associated with the pressed key to use given the previous two letters. For example, 
so since the is a commonly occurring string, the entry in table 902 addressed by (t, h, 3) returns e, or more concisely the 
predictive letter entry 2 is returned to indicate that the second letter of the group of letters d, e, and f associated with 
the three key is the predicted letter. Of course, letter frequency table 902 could be altered to return more than a single 
letter. 

[0225] In this embodiment, letter frequency table 902 was empirically generated using a collection of e-mail. Appendix 
55 || is a computer program listing that was used to generate letter frequency table 902 that is illustrated in Figures 10A 
to 10T. Briefly, the computer program implements a process that sequentially steps through the data provided and (i) 
for each possible single letter determines the most likely letter that follows for each key on the keypad; and (ii) for each 
possible combination of two letters determines the most likely letter that follows for each key on the keypad. In this 
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embodiment, the most likely letter is the letter having the greatest frequency after the single letter. Similarly, the most 
likely letter is the letter having the greatest frequency after the combination of two letters. If there is a tie in the frequency, 
the first letter associated with a key is selected. Of course, other measures of likelihood could be used to generate the 
entries in table 902. 

s [0226] Thus, in Figures 10A to 10T, the first of the ten columns, i.e., the left most column, is the two letter sequence 
and the first row, i.e., the top row is the keys on the key pad used to enter text. A combination of an entry in the first 
column and a key in the top row is used to select the predicted text entry. Thus, using the example of th, this two key 
sequence appears in the first column of Figure 100. When the three key is pressed, the letter in the row with th as the 
first entry and in the column with three as the first entry, i.e., e, is retrieved. Alternatively, if the four key is pressed, 

10 letter i is retrieved from the table. 

[0227] In this embodiment, table 902 is a buffer of two bit numbers. Each two bit number has a value in the range 
of zero to three, and the two bit number represents a predicted letter for the pressed key. Thus, for a two key labeled 
with letters A, B and C, a zero represents A; a one represents B; and a two represents C. In general, the number of 
bits used is determined by the key that represents the maximum number of characters. In this embodiment, the max- 

15 imum number of characters represented by a key is three. The number of storage bits required is an integer S where 
S is the smallest number such that 2**S is greater than or equal to the maximum number of characters represented 
by a key. 

[0228] In this embodiment, three indices iO, M, and i2 are used generate a table index that in turn is used to access 
a particular predictive letter entry in table 902 of two bit numbers. Each letter is represented as a number, i.e., a letter 
20 entry, with letter A being zero, letter B being a one, letter C being a two, and so forth with letter Z being twenty-five. A 
space element is assigned a space element value of twenty-six. Thus, in this embodiment, there are twenty-seven 
possible characters. 

[0229] Upon the initial entry to process 1100 (Fig. 11), letter indices iO, i1 , and i2 were set to twenty-six in the initial 
processing of the entry card to indicate that the text buffer is empty. Also, as explained more completely below, as each 

25 letter of text is entered, letter indices iO and i1 are updated and stored in memory 716. 

[0230] However, in another embodiment, an initialize indices process is the first operation in predictive text entry 
process 1100. In this embodiment, for the first letter entered, letter indices iO and i1 are set to twenty six; for the second 
letter entered, letter index iO is set to twenty six and letter index i1 is set to the value of the letter in text buffer 903; and 
for all letters entered after the first two, the value associated with next to the last letter in text buffer 903 is assigned 

30 to letter index iO and the value associated with the last letter in text buffer 903 is assigned to letter index i1. 

[0231] Punctuation key check 1101 determines whether the zero key was pressed, i.e., the key selected to represent 
punctuation. 

[0232] If the zero key was pressed, processing transfers from check 1101 to process punctuation entry 1102. Process 
punctuation entry 1102 sets index i2 to twenty-six, and sends the space element value to display letter process 1108. 
35 Display letter process 1108 transfers the space element value to display module 712 which in turn drives a space in 
the text entry on display screen 705. This completes the operation of process data entry for a zero key press and so 
processing returns to key press check 820. 

[0233] If the zero key was not pressed, processing transfers through punctuation key check 1 1 01 in data entry process 
1100 to key one-to-nine check 1103, i.e., to a data entry key check. If the pressed key was any one of keys one to 
40 nine, check 1103 transfers to set letter index process 1104 and otherwise to rotate last entry process 1109. 

[0234] In set letter index process 1104, one is subtracted from the numeric value of the pressed key and the resulting 
value is assigned to index i2. Set index process 1104 transfers to generate table index process 1105. 
[0235] Generate table index process 1105 combines indices iO, i1 and i2 to create a table index. In this embodiment, 
table index TABLEINDEX is defined as: 

45 

TABLE INDEX = (((iO * 27) + i1) * 9) + i2 

Upon completion of generate table index process 1105, generate text entry process 1106, retrieves the two bit value 
50 in the table at the location pointed to by table index TABLEJNDEX and converts the two bit value to a letter represented 
by the two bit value. 

[0236] Generate text entry process 1106 transfers to update index process 1107, which in turn stores the value of 
letter index i1 as letter index iO; stores the value of the retrieved letter in letter index i1 ; and stores the predicted letter 
in text buffer 903. While this step assumes that letter indices iO, and i1 are stored and accessed each time in process 
55 827, alteratively, the last two letters in text buffer 903 can be retrieved and assigned to indices iO and i1 , respectively, 
as described above. 

[0237] Update index process 1107 transfers to display letter process 1108. Display letter process 1108 sends infor- 
mation to display module 712 which in turn generates the predicted letter on display screen 705. 
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[0238] If the pressed key is not one of keys one to nine, i.e, is not a data entry key, processing transfers from check 
1103 to rotate last entry 1109. Recall that data key check 826 determined whether the pressed key was one of the zero 
to nine keys, or the # key. Thus, since checks 1101 and 1103 determined that keys zero to nine were not pressed, the 
only key press remaining is the # key, i.e., the rotate entry key, which indicates the user wants a letter different than 
s the one entered last in text buffer 903. In rotate last entry 1109, the last character, i.e., the right most character, in text 
buffer 903 is replaced by the next character in the set of characters assigned to the last key pressed before the # key 
was pressed. Again, the use of the # key is illustrative only and is not intended to limit the invention to the use of that 
particular key to rotate an entry. 

[0239] For example, if the last character in the text buffer 903 was a t and the # key is pressed, process 1109 changes 
10 the t to u. If the # key is pressed again, the u is changed to a v. Alternatively, if the last character in text buffer 903 
was a u and the # key is pressed, process 1109 changes the u to a v. If the last character in text buffer 903 was a v 
and the # key is pressed, process 1109 changes the v to a t. If index i1 is stored, as the last character in text buffer 
903 is rotated, index i1 is updated. 

[0240] Text entry in cellular telephone 700 in different languages or contexts can be supported by using different 
15 letter frequency tables. For example, for plumbers, the prediction table can be based on text about plumbing proce- 
dures. For Frenchmen, the prediction table can be based on French text. Also, multiple letter frequency tables could 
be stored in cellular telephone 700, or selectively transmitted to cellular telephone 700, and a particular letter frequency 
table would be selected on an entry card. 

[0241] In addition, an entry in the table can be more that a single letter, and thus save even more key strokes. For 
20 example, if the text buffer contains sche then typing a 3 could return dule rather than just d. Further, this novel method 
of text entry can be utilized with other than a cellular telephone. The method is applicable to any device that has several 
characters assigned to a single key on a keypad. 

[0242] In the above embodiment, the English alphabet and a space element were used as the character set. Thus, 
the number 27 used in defining the table index is just the number N of characters in the set. Similarly, the number 9 
25 used in defining the table index is just the number M of keys in the keypad that represent two or more different char- 
acters. Hence, predictive text entry method is not limited to text and is directly applicable to any keypad where each 
key represents a plurality of different characters. 

[0243] In the embodiment of Figures 7, 8, and 9, client module 702 and server module 749 communicate over CDPD 
network 710. However, this architecture is illustrative only of the principles of the invention and is not intended to limit 

30 the invention to the particular architecture described. Client module 702 and server module 749 can use a wide variety 
of two-way data communication links to exchange resource locators, e.g., URLs, and TIL decks. For example, the 
communications link could be a switched voice circuit in which the client module and server module communicate 
using modems. Alternatively, the communications link could be any other packet switched network, so long as there 
is some way for client module 702 to get requests to server module 749 and for server module 749 to send data back 

35 to client module 702. Further, a special purpose server could be used in place of HTTP server 749. For example, the 
principles of this invention can be used over various data transport mechanisms including circuit switched data and 
packet switched data. These data transport mechanisms are being defined and implemented for most of the cellular 
network standards including GSM, TDMA, and CDMA. 

[0244] In the configuration of airnet network 750 (Fig. 7), client module 702 communicated directly with a server 
40 computer 743. In another embodiment, as illustrated in Figure 5, the two-way data communication device first com- 
municates with an airnet network translator 500 that in turn communicates with the appropriate server. In this embod- 
iment, the operation of two-way data communication devices 100 and 101 is similar to that described above for cellular 
telephone 700, except the method field in the request generated in process 802 has a different form. For example, 
using the same information as before, the method field in this embodiment is: 
45 GET http://www.libris.com/airnet 

/home.cgi?&cost=1 ANTP/1.0 
The method field includes the full address of the server, the expected cost of the service, and the version of the protocol 
used for communicating with airnet network translator 500. The two-way data communication device transmits the 
HTTP request including the complete URL to airnet network translator 500. 
50 [0245] Figure 1 2 is a more detailed block diagram that illustrates the structures in one embodiment of airnet network 
translator 500. In this embodiment, airnet network translator 500 is a computer running under the UNIX operating 
system with an interface to CDPD network 710. Such computers are well known to those skilled in the art. Thus, herein 
only the structures and processes that must be added to such a computer are described. 

[0246] Airnet network translator 500 supports internet protocol (IP) connections over CDPD network 710 and with 
55 each computer network with which translator 500 can interact. In this embodiment, each of the modules in network 
translator 500 are processes that are executed by the processor in the computer. Control module 1201 is a daemon 
that listens for transmissions over an IP connection from CDPD network 710. When control module 1201 accepts a 
transmission, control module 1201 spawns an ANT request processor 1204, which in this embodiment is a process, 
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as indicated above. While in Figure 12, only one ANT request processor 1204 is shown, there is an ANT request 
processor spawned for each transmission that control module 1201 accepts and the ANT request processor remains 
active until the communication is terminated. 

[0247] Figure 1 3 is a process flow diagram that illustrates the operation of ANT request processor 1 204. This process 
s flow diagram considers transmissions that utilize both TCP/IP and UDP/IP. However, the processes that are specific 
only to TCP/IP are enclosed in dashed-line boxes. Upon being spawned for a TCP/IP, in establish connection process 
1300, ANT request processor 1204 establishes a TCP connection using a TCP module in the server with the client 
module over CDPD network 710. After the connection is established processing transfers from process 1300 to request 
received check 1301. 

10 [0248] If UDP is being used, upon being spawned ANT request processor 1204 initiates processing in request re- 
ceived check 1 301 . In check 1 301 , ANT request processor 1 204 determines whether the request from cellular telephone 
700 (Fig. 12) has been received and stored in memory 1210. Memory 1210 represents both RAM and non-volatile 
memory in this embodiment. When the request has been received and stored, processing transfers from check 1301 
to retrieve data process 1302. 

15 [0249] In retrieve data process 1302, ANT request processor 1204 retrieves information concerning the source of 
the URL, i.e., client module 702 of cellular telephone 700 from customer database 1213, and the destination specified 
in the URL, i.e., the designated server, from server database 1212. Both databases 1212 and 1213 are stored in 
memory 1210. A customer record in database 1213 includes, for example, a carrier address, e.g., an IP number, an 
airnet network translator account number, billing information, and server subscriptions. A server record in database 

20 1212 includes a server IP address, name, category, and class of service. Class of service refers to the pricing of the 
service, e.g., basic services, premium services, or pay-per-view services. Other pricing schemes can be supported in 
other implementations. When the information is retrieved for the server and service specified in the URL, and for the 
customer, processing transfers to valid request check 1303. 

[0250] In valid request check 1303, ANT request processor 1204 determines, for example, whether client module 
25 702, i.e., the customer, is authorized to access airnet network translator 500; whether client module 702 is authorized 
to access the server specified in the URL; whether the specified server is available through translator 500; and whether 
the specified server supports the requested service. Thus, valid request check 1303, validates the client, the server, 
and the client/server pair. Also, since an estimated cost is included in the request, the status and credit limits on the 
customer's account could be checked to determine whether the estimated cost is acceptable. If all of the checks are 
30 true, processing transfers to create HTTP request process 1306. Conversely, if any one of the checks is untrue, valid 
request check 1303 passes information concerning the error to return error process 1304. 

[0251] Return error process 1 304 launches a CGI program stored in memory 1210 based on the information received 
and passes appropriate information to the CGI program. The CGI program builds an appropriate PIDL deck describing 
the error and converts the PIDL deck to a TIL deck, as described above. When the TIL deck describing the error is 
35 complete, return error process 1 304 transfers processing to log transaction process 1315 that is described more com- 
pletely below. 

[0252] If all the checks in valid request check 1303 are true, create HTTP request 1306 converts the request in 
memory 1211 to a request specific to the server specified, which in this embodiment is a HTTP request. For example, 
for the above request, create HTTP request process 1306 generates a method field, such as 
40 GET /airnet/home.cgi?&client=xyz&cost=1 HTTP/1.0 In this embodiment, the method field includes the same 

information as in the embodiment described above, and in addition, the method field includes a client identification and 
the estimated cost. 

[0253] After create HTTP request process 1306 is complete, ANT request processor 1204 accesses TCP module 
1203 in establish server connection process 1307 for TCP/IP and transfers to secure transmission check 1308 for 
45 UDP/IP. In establish connection process 1 307, a connection is made between the server designated in the client request 
and the TCP interface module (not shown) so that data can be transmitted between airnet network translator 500 and 
the server. When the TCP connection to the server is established, ANT request processor 1204 transfers processing 
from establish server connection process 1307 to secure transmission check 1308. 

[0254] In secure transmission check 1308, ANT request processor 1204 determines whether the HTTP request from 
50 the client requested a serverthat utilizes a protocol that supports encryption. If such a server was requested, processing 
transfers to negotiate process 1309 and otherwise to transmit request process 1310. 

[0255] In negotiate process 1309, ANT request processor 1204 negotiates an encryption technique with the server. 
Upon completion of the negotiation, processing transfers from process 1309 to encryption process 1311 . In encryption 
process 1311, the HTTP request is encrypted using the negotiated encryption technique, and then processing transfers 
55 to transmit request process 1310. 

[0256] In transmit request process 1310, the HTTP request is sent from memory 1210 to the HTTP server. When 

the transmission is complete, ANT request processor 1204 goes to result received check 1312. 

[0257] As described above, upon receipt of the request, the HTTP server services the request. Upon completion of 
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servicing the request, the HTTP server returns either a PIDL deck or a TIL deck to airnet network translator 500. The 
deck is stored in memory 1210. If the server does not convert the PIDL deck to a TIL deck, the translation is done by 
airnet network translator 500. 

[0258] When the deck is received and stored, ANT request processor 1204 transitions from check 1312 to transmis- 
s sion completed process 1313 for TCP/IP and to secure transmission check 1314 for UDP/IP. ANT request processor 
1204 closes the TCP circuit with the server in transmission completed process 1313. Upon closing the server TCP 
connection, processing transfers to secure transmission check 1314. 

[0259] If the server utilized encryption, the deck stored in memory 1210 is encrypted. Thus, secure transmission 
check 1314 transfers processing to decryption process 1316 if encryption was used and otherwise to log transaction 
10 1315. 

[0260] In decryption process 1316, the encrypted deck is decoded and stored in memory 1210. Also, after the de- 
coding, if the deck must be converted to a TIL deck, the translation is performed. Decryption process 1316 transfer to 
log transaction process 1315. 

[0261] In log transaction process 1315, ANT request processor 1204 writes a description of the transaction to trans- 
15 action log 1211 in memory 1210. In this embodiment, each transaction record includes a customer identification, a 
server identification, time required for the transaction, cost of the transaction, and a completion code. In one embodi- 
ment, for security purposes, each cellular telephone is assigned to only one customer and only one account. 
[0262] After the transaction is logged, processing transfers to transmit result 1317. In transmit result 1317, ANT 
request processor 1204 returns the deck to client 702. After the deck is transmitted, ANT request processor 1204 is 
20 terminated. 

[0263] In one embodiment, if an airnet network translator is fully loaded and another transmission comes in, the 
translator returns the address of another airnet network translator and refuses the transmission. The cellular telephone 
transmits the message to the other airnet network translator. In yet another embodiment, all incoming transmissions 
are directed to a router. A plurality of airnet network translators are connected to the router. The router monitors the 

25 status of each translator. Each incoming transmission is routed to the least busy translator, which in turn responds to 
the transmission and performs the necessary operations for continuing communications with the client module. 
[0264] In the above description of client module 702, module 702 interacted with components within the cellular 
telephone to perform the various operations specified by the user. To insulate client module 702 from the exigencies 
of various cellular telephones to the extent possible, a general architecture for client module 702 is described more 

30 completely below. This general architecture is designed to have specific manager modules that interact with the mod- 
ules described above within the cellular telephone and to provide standard information to the remaining manager 
modules within client module 702. The manager modules with client module 702 form an interpreter that interprets TIL 
decks to generate a user interface; interprets data input by the user; and interprets the TIL decks so that the data input 
by the user is combined with an appropriate resource locator and either a message is sent to an appropriate server, 

35 or another local TIL deck is interpreted by client module 702. While this embodiment is for a cellular telephone, the 
manager modules are generic and so are applicable to any client module in a two-way data communication device. 
[0265] This approach limits the modifications that must be made to client module 702 to implement the principles of 
this invention in a wide variety of two-way data communication devices over a wide variety of two-way data commu- 
nication networks. Also, in the above embodiment, client module 702 supported communications and interactions over 

40 the cellular telephone network. However, client module 702 can also support local services on cellular telephone 700. 
Typical local services includes local messages, an address book, and preconfigured e-mail replies, or any combination 
of such services. 

[0266] In this embodiment, client module 702 includes a plurality of manager modules including a navigation manager 
module 1401, a network manager module 1402, a TIL manager module 1403, an archive manager module 1404, a 
45 local manager module 1405, an event manager module 1406, a timer manager module 1407, a user interface manager 
module 1408, a memory manager module 1409, and a device dependent module 1410. 

[0267] Navigation manager module 1401 handles card and deck navigation as well as managing any caches. Nav- 
igation manager module 1401 owns and manages a history list and as well as a pushed card list. In addition, navigation 
manager module 1401 functions as the main line of client module 702; does all event distribution; and supports local 
50 services. 

[0268] For local services, like local message store, there are two basic approaches that can be used. First, local 
services are implemented in a CGI-like manner. Each local service has an entry point which is called with an argument 
list. A TIL deck is returned via the event manager. From that point on, the TIL deck is processed in the standard manner. 
This approach limits local services to the same constraints as remote services. A less restrictive approach is to allow 
55 the local service to field events instead of the standard event loop. The local service would construct TIL cards on-the- 
fly and feed them to user interface manager 1406. Note that the local service would need to cooperate with the standard 
event loop with regard to the history, the pushed card list, and any other state that is normally managed by the event 
loop. Table 4 is a listing of processes for the architecture for navigation manager module 1401 . 
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TABLE 4 

ARCHITECTURE FOR NAVIGATION MANAGER MODULE 14 01 

5 

ProcessEvents (void) ; 

PushLocation (void * location. Boolean forStack) ; 
10 void * PopLocation (Boolean EorStack) ; 

void * CurrentLocation ( ) ; 
struct LOCAL_SERVICE { 
char name [50] ; 

15 

FUNC HandleEvent (Event * pevent) ; 
FUNC StartLocalService (void) 
FUNC StopLocalService (void) ; 

20 ) . 

static LOCAL_SERVICE localServices [ ] = { ... }; 
STATUS HandleEvent (Event * pevent); 
STATUS StartLocalService () ; 

25 

STATUS StopLocalService 0 ; 



[0269] Routine ProcessEvents is the main entry point for event processing in client module 702. Typical events 
30 include key presses on the keypad, choice selection for a choice card, text entry for an entry card, network events, 
and history events. Routine ProcessEvents can be called at any time to process an event or events. Routine Proces- 
sEvents does not return until all events on a queue generated by event manager module 1406 are processed. If a local 
service is running, events are distributed to the local service before being processed by routine ProcessEvents. 
[0270] The remaining routines in Table 4 are called internally to navigation manager module 1401 and by local serv- 
35 ices. Routine PushLocation pushes a location on the history list and issues a request for that location. The forStack 
flag indicates a stack push of local cards. 

[0271] Routine *PopLocation pops a location on the history stack and issues a request for the top location of the 
history stack. In routine *PopLocation the forStack flag indicates that all cards since the last stack push should be 
popped. 

40 [0272] Routine 'CurrentLocation returns the current location the current URL being displayed. 

[0273] As shown in Table 4, each local service provides a number of functions. If a local service is running, function 
HandleEvent, the local service's event handler, is called before any processing by navigation manager module 1401. 
If the event is handled by the local service, the event is not processed any further. 

[0274] Function StartLocalService is the local services start function. Function StartLocalService is called before any 
45 events are distributed to the local function. Similarly, function StopLocalService is the stop function for the particular 
local service. Function StopLocalService is called when no more events are distributed to the local service. 
[0275] Network manager module 1402 insulates the rest of client module 702 from the specific networking protocol 
used over the cellular telephone network. Network manager module 1402 delivers requests to the server specified in 
the URL via the cellular telephone network interface; segments responses from the server for lower latency; delivers 
so responses from local services to navigation module 1401 via event module 1406; handles request/response cycle (e. 
g. cancellation, retry strategy) with the server over the cellular telephone network; can receive asynchronous messages 
from the server; performs memory management of TIL decks; performs caching of TIL decks; handles all negotiations 
concerning protocols and server scaling with the server; handles any encryption for information exchanged between 
cellular telephone 700 and the server. 
55 [0276] In some cellular telephone, the maximum message size is fixed. However, for UDP and TCP messages, a 
more direct interface is used that bypasses this limitation of message passing. It is important to avoid copying network 
data from memory buffer to memory buffer as such copying increases the memory "high water mark" as well as de- 
creases performance. Since different cellular telephones have different interfaces for delivering network data, network 
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manager module 1402 manages the network data. In this way, network data is only copied from the network buffer for 
long-term storage. 

[0277] When a message or reply arrives, network manager module 1 402 uses event manager module 1 406 to report 
that fact. However, access to the data by other manager modules in client module 702 is through a protocol that allows 
s storage of data in a variety of fashions on different telephones. Any transparent, short-term caching of TIL data is 
handled by network manager module 1402. Table 5 is one architecture for network manager module 1402. 

TABLE 5 

SPECIFICATION FOR NETWORK MANAGER MODULE 1402 
10 typedef short TID; 

void NMJnit(void); 

void NM_Terminate(void); 

TID NM_SendRequest (void *requestData, int length, Boolean ignoreCache); 
NM_CancelRequest (TID TRANSACTIONS); 
NM_DataType(TID TRANSACTIONS); 

NM_GetData(TID TRANSACTIONS, void *data, int length, Boolean 'complete); 
void *NM_HoldData (TID TRANSACTIONS); 
NM_ReleaseData(TID TRANSACTIONS); 
20 TID NM_StartData(int data Type, char *requestData, int length); 

STATUS NM_EndData(TID TRANSACTIONS); 
STATUS NM_SetDataLength (TID TRANSACTIONS, int length) ; 
STATUS NM_GrowDataLength (TID TRANSACTIONS, Int grow); 
int NM_GetDataLength(TID TRANSACTIONS); 
void *NM_GetDataPointer (TID TRANSACTIONS); 
STATUS NM_DeliverData (TID TRANSACTIONS); 

[0278] Network manager module 1402 identifies each network data transaction by a 16-bit transaction identification 
30 code TID. Network manager module 1402 increments transaction identification code TID by one for each new trans- 
action. Transaction identification code TID rolls over after Oxffff. 

[0279] Routine NMJnit initializes network manager module 1402 and so is called before any other calls in network 
manager module 1402. Routine NM_Terminate closes processing of network manager module 1402 and so is called 
after all other calls in network manager module 1402. 

35 [0280] Network manager module 1402 uses routine TID NM_Send Request as the standard process of sending a 
request to the server. Pointer "requestData in the call to routine TID MN_SendRequest is defined by the server protocol. 
Similarly, the state, e.g., the Boolean value, of variable ignoreCache is used to indicate whether any cached replies 
should be ignored. After sending the request, this routine returns a server transaction identification code TRANSAC- 
TIONS. A local service can also send a request to the server. 

40 [0281] When the user instructs client module 702 to cancel a request, network manager module 1402 calls a routine 
NM_CancelRequest with cellular telephone transaction identification code TID and server transaction identification 
code TRANSACTIONS. Routine NM_CancelRequest issues a command to the server to cancel the specified request. 
[0282] When data are received from the network, the data can be either a response to a request sent by routine TID 
MN_SendRequest, or by a local service. Thus, in response to receiving data from the server, network manager module 

45 1402 generates an event that includes server transaction identification code TRANSACTIONS and the type of data 
DATAType. For replies to requests sent by routine TID MN_SendRequest, server transaction identification code 
TRANSACTIONS is the same as the one returned by the matching call to routine TID MN_SendRequest and data 
type DATAType indicates that the data is a response. For local service originated messages, server transaction ID is 
new, and data type DATAType depends on whether the data is an e-mail, pushed TIL, or another type. 

50 [0283] After the network event is received by event manager module 1406, and navigation manager module 1401 
distributes control of the event to network manager module 1402, network manager module 1402 users the server 
transaction identification code TRANSACTIONS and the remaining routines in Table 5 to process the data. 
[0284] Routine NM_DataType is used to return the particular data type dataTYPE, e.g, reply, MIME, server push, 
etc. Routine NM_GetData sets a pointer to the data identified by server transaction identification code TRANSACTIO- 

55 NS, retrieves the length of the data, and determines whether all the data has been received. The interface provided 
by this routine allows the first part of a data stream, e.g. the first card of a TIL deck, to be processed by client module 
702 before the rest of the deck is received. 

[0285] Routine NM_HoldData is called before calling routine NM_GetData to hold the data and thus insure that the 
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data remains valid during processing by client module 702. If the data is not held, the data can be deleted or moved 
with the internal buffers of network manager module 1402. If the data is held, routine NM_ReleaseData is called after 
network data has been processed to release the data. 
[0286] Routines TID NM_StartData, NM_EndData, 
s NM_SetDataLength, NM_GrowDataLength, NM_GetDataLength, NM_GetDataPointer, and NM_DeliverData are used 
internally by network manager module 1402, and by local services to deliver data. By allowing local services to use 
these routines, the same buffers can be used to store both network and locally generated data thereby reducing the 
amount of memory required to support client module 702. 

[0287] Routine TID NM_StartData creates a new data transaction and triggers a data delivery event. Routine 
10 NM_EndData is called when all data for the given server transaction identification code TRANSACTIONId has been 
transmitted. Routine NM_SetDataLength sets the data segment to a given length and may cause the location of the 
data to change. Routine NM_GrowDataLength grows the data segment by a given length and also may cause the 
location of the data to change. Routine NM_GetDataLength returns the length of the data segment. Routine 
NM_GetDataPointer returns a pointer to the data. This routine is preferably called before writing into the data buffer. 
15 Also, this routine is preferably called whenever the data's location may have changed. Routine NM_DeliverData can 
be called when at least one card has been stored to reduce latency while the other cards are being generated. 
[0288] TIL manager module 1403 insulates the rest of client module 702 from changes to the TIL specification. The 
interface provided by TIL manager module 1403 has the following characteristics: removes the need for parsing by 
the rest of client module 702; uses cursors to avoid generating data structures on-the-fly; does not need an entire deck 
20 to operate; and handles TIL versioning. 

[0289] Each TIL deck contains a major and a minor version number. The minor version number is incremented when 
TIL changes in a way that does not break existing TIL manager modules. The major version number is incremented 
for non-compatible versions of TIL. 

[0290] Each TIL deck has the same hierarchy. One embodiment of this hierarchy is presented in Table 6. In Table 
25 6, indentation is used to represent the relationships of the various hierarchical levels. 



TABLE 6 
TIL DECK HIERARCHY 

options 
35 softkeys 

options 

card 

options 

40 

softkeys 

options 
formatted text 
45 formatted lines 

entries 

options 

50 formatted line 

The interface presented in Table 7 for TIL manager module 1403 is designed with the assumption that TIL is a direct 
tokenization of PIDL as described in Appendix I. However, the interface does not have any dependencies on that 
tokenization and can support other PIDL encoding techniques. Given the above assumption, the opaque pointers 
55 described below are actual pointers into the TIL deck itself. A rudimentary object typing scheme based on where in 
the deck the opaque pointer points can be used to implement the generic functions described below. If this object 
typing is not feasible due to details of TIL encoding, the generic functions can be replaced with specific functions. 



30 

deck 
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TABLE 7 

ARCHITECTURE FOR TIL MANAGER MODULE 
typedef char *opaque,- 
typedef opaque Deck; 
typedef opaque Card; 
typedef opaque Text; 
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typedef opaque Entry; 
typedef opaque Option; 
typedef opaque SoftKey; 
typedef opaque Object; 

/* Generic functions */ 

FirscOption (Obj ect ob j , Option *o) ; 

/* obj is a card, softkey, entry, or deck */ 
GetSof tkey (Ob ject obj, Option *o) ; 

/* obj is a card or deck */ 
GetText (Object obj, Option *o) ; 

/* obj is a card or entry */ 

/* Deck functions */ 

SetDeck(Deck d, int length); 

/* tells module which deck to use */ 
DeckGetCard (Card *c, int num) ; 

-or- 

DeckGetCard (Deck d, Card *c, int num) ,- 

/* Card functions */ 

int CardType (Card c) ,- 
CardFirstEntry (Card c, Entry *e) ; 
CardLookupSof tkey (Card c, int num, Softkey *s) ,- 
CardlsLast (Card c) ,- 

/* Option cursor functions */ 
OptionNext (Option *o) ; 
char *OptionKey (Option o) ,- 
char *OptionValue (Option o) 

/* Entry cursor functions */ 

/* Text (and image) cursor functions */ 

TextNextToken (Text *t, int *type, int ^subtype, 

int *length, char *data) ; 



[0291] Archive manager module 1404 stores and retrieves long-lived information. This information includes: data 
related to the server's location and/or required to support server scaling; data related to encryption; TIL caching (trans- 
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parent to user); TIL storage (specified by user); and message storage and retrieval (see local manager module). Archive 
manager module 1404 should support a variety of nonvolatile memory schemes that are provided by the two-way data 
communication devices. 

[0292] Local manager module 1405 is an interface to local device resources, such as local messages, address book 
s entries, and preconfigured e-mail replies. Local manager module 1405 should also define an abstract interface to 
navigation manager module 1401 for use by archive manager module 1404. 

[0293] Table 8 is an architecture for an interface within local manager module 1405 to access to an address book 
stored on cellular telephone 700. The name of a routine in Table 8 is descriptive of the operations performed by the 
routine. 

10 

TABLE 8 

ARCHITECTURE FOR ADDRESS BOOK ACCESS 

int NumAddresses(); 

char *AddressName(int num); 
15 char *AddressGetEMail(int num); 

// returns e-mail address 

char *AddressGetPhone(int num); 

// returns phone number 
20 char * AddressGetFax(int num); 

// returns fax number 

SetAddress(int num, char 'name, char *email, char *phone, char *fax); 
DeleteAddress(int num); 
lnsertAddress(int before); 

25 

[0294] Table 9 is an architecture for an interface within local manager module 1405 to access predetermined replies 
stored on cellular telephone 700. The name of a routine in Table 9 is descriptive of the operations performed by the 
routine. 

30 TABLE 9 

ARCHITECTURE FOR PREDETERMINED REPLY ACCESS 
int NumReplies(); 
char * GetReply(int num); 
DeleteReply(int num); 

35 

SetReply(int num, char *text); 
TnsertReply(int before); 

[0295] Table 10 is an architecture for an interface within local manager module 1405 to access messages stored 
40 locally on cellular telephone 700. The name of a routine in Table 10 is descriptive of the operations performed by the 
routine. 

TABLE 10 

ARCHITECTURE FOR LOCALLY STORED MESSAGE ACCESS 
45 int NumMessagesQ; 

void *FirstMessage(); 
void *NextMessage(); 
int MessageType(void *msg); 
// e.g. e-mail, TIL, etc. 

50 

void *MessageContent(void *msg); 

void *SaveMessage(int type, void "content, int contentLength); 
DeleteMessage(void *msg); 

55 [0296] Event manager module 1406 handles the distribution of events. In this embodiment, events include low-level 
events like key presses and higher level navigation and user interface events. There are typically only a small number, 
of events at any one time. The main event loop in the two-way data communication device dependent module keeps 
calling EM_GetNextEvent() until no events are left in the queue. Note that processing one event can cause another 
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event to be pushed onto the queue. The main event loop is not restarted until another event is pushed onto the queue 

due to a user key press or a network event. 

[0297] In this embodiment, the event types include: 

s 1) keypad events, i.e., pressing of a key; 

2) choice events relating to a current choice card, e.g., the user selecting choice three; 

3) text entry events relating to a current entry card, e.g., the user keying in "Hello"; 

4) network events, e.g., response arrived, request arrived, transaction terminated, network status; and 

5) history events, e.g., pop, pop to marker. 

10 

[0298] Table 11 is an architecture for event manager module 1406. As in the other tables herein, the name of a 
routine in Table 11 is descriptive of the operations performed by the routine and in addition a brief description is given 
in the comment field. 



15 

TABLE 11 

ARCHITECTURE FOR EVENT MANAGER MODULE 14 06 



struct Event { 
int type ; 
void *data; 

/* e.g. keycode, choice num, entry 
text, status code, other data */ 



} 

EM_QueueEvent {int type, void * data) ; 

/* Adds event at end of queue*/ 
EM_GetNextEvent (Event * event); 

/*Pops next event*/ 
EM_PeekNextEvent (Event event) ; 

/*Peeks at next event*/ 



[0299] Timer manager module 1407 allows timer events to support timeouts, animation, and other time-domain fea- 
tures. Timeouts are delivered via event manager module 1406. 
45 [0300] Table 12 is an architecture for timer manager module 1407. As in the other tables herein, the name of a routine 
in Table 12 is descriptive of the operations performed by the routine. 

TABLE 12 

ARCHITECTURE FOR TIMER MANAGER MODULE 1407 

so Timerlnit(); 

int TimerSet (int milliseconds, int code, void*/Returns a timer identification timerld to be used for cancellations*/ 

TimerCancel (int timerld); 

TimerCancelAIIO 

55 

[0301] User interface manager module 1408 handles interactions with the keypad and the display. Each of the three 
types of user interfaces defined in Table 1 above requires a different version of user interface manager module 1408. 
For most cellular telephones, only one card at a time is used. However, some cellular telephones can display multiple 
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cards at once and so would require a different version of user interface manager module 1408 from the version that 
handled display of only one card at a time. 

[0302] In this embodiment, user interface manager module provides a user interface for the three types of cards 
display, choice, and entry; provides hooks for custom user interfaces for the address list and e-mail reply entry; only 
s cares about the user interface aspects of cards and provides no navigation, argument, or option processing; handles 
all text and graphic layout including word wrapping; handles scrolling of text; operates from PIDL data structures; 
generates keyboard events, some of which may be generated by soft keys; and generates high-level events, e.g. next 
card, choice entry 3, text entry "IBM". 

[0303] Table 1 3 is an architecture for processing cards by user interface manager module 1408. As in the other tables 
10 herein, the name of a routine in Table 1 3 is descriptive of the operations performed by the routine. 

TABLE 13 

ARCHITECTURE FOR CARD PROCESSING BY Ul MANAGER MODULE 1408 
void UI_StartCard -Card c); 
15 /* called to begin display and processing of a given card*/ 

void Ul EndCard -Card c); 

/* called when a card is no longer to be displayed*/ 
Boolean UI_HandleEvent (Event *pevent) ; 
20 /'returns true if the event is handled, false if not*/ 

[0304] Table 14 is an architecture for the user interface implementation by user interface manager module 1408. As 
in the other tables herein, the name of a routine in Table 14 is descriptive of the operations performed by the routine. 

25 TABLE 14 

ARCHITECTURE FOR Ul IMPLEMENTATION BY Ul MANAGER MODULE 1408 
UI_LayoutCard (Card c, Boolean draw, Pore callback) 

/* relies on global data; needs to be able to: draw as it goes; and note the special function of the currentLine 
(e.g. none, choice, softkey) */ 
30 int numLines, fireVisible, lastVisible, currentLine; 

char currentEntry[80]; 
int currentChoice; 
void *currentSoftkey; 
Card currentCard; and 

35 

...other info as needed for in-line scrolling 

[0305] The callback routine is notified of the special function of each line as the line is laid out. Thus, routine 
UI_LayoutCard can be used to scroll to a particular choice. If the current line is too wide to display all at once, horizontal 

40 scrolling is used to display the complete line, one display width at a time. 

[0306] Memory manager module 1409 is optional, and is used in two-way data communication devices that do not 
support dynamic memory allocation. In these devices, all memory allocation and releases must go through memory 
manager module 1409. Also, by allocating memory in advance via memory manager module 1409, client module 702 
does not run out of memory due to some other process on the device using up memory. 

45 [0307] In one embodiment, the airnet network translator described above was used with an Internet server to com- 
municate with client module. The Internet server was a U NIX computer running the Mosaic HTTP server. The executable 
code was generated by compiling the source code on a computer running the Sun Microsystems Operating System 
Solaris 2.4 using Sun Microsystems compiler SunPro C and C#, and the Sun Microsystems SDK make utility. All of 
these products are available from Sun Microsystems of Mountain View, California. 

50 [0308] Various embodiments of a novel interactive two-way data communication system, a two-way data communi- 
cation device and an airnet network architecture have been described herein. These embodiments are illustrative only 
of the principles of the invention. 

APPENDIX I 

55 

A DESCRIPTION OF PIDL AND TIL Unpublished © 1995 Libris, Inc. 

[0309] The main structure of PIDL is described by an abstract syntax. This appendix describes the elements of the 
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language and their semantics. In the syntax description of each element, an element is defined in an enhanced BNF. 



d . . — U 


llle GlGlllGIIL d lb (JcllllcU do U 


d .. — U 

: : = c 


Lllc clcillcill d lb UcliricU db U Ol O 


b c 


the element b followed by element c, the intervening space is just for clarity 


a|b|c 


element a or element b or element c 


{a} 


the element a is optional 


{a}* 


the element a may appear zero or more times in a row 


{a}+ 


the element a may appear one or more times in a row 


abc 


the characters abc literally 


ol(a) 


an option list with zero or more topions of the element a, see Options below 



[0310] In general, the element blank-space can optionally appear between any two other elements. To keep the 
diagram clear, it has been omitted except where required. Where a blank-space is illegal or treated specially, it is noted. 

20 

The PIDL ELEMENTS 



[0311] 

25 deck ::= deck-header {softkey}* {card}+ deck-footer 

deck-header ::= <PIDL ol(deck-options) > 
deck-options ::= o-args | o-cost | o-ttl 
deck-footer ::= </PIDL> 

A deck consists of one or more cards. There must be at least one card. A deck may also have a number 
30 of softkeys defined that stay in force for the whole deck. See soft keys below for the syntax and full 

description, 
o-cost ::= cost= value 

o-ttl ::= ttl= integer 

Additional arguments to be passed on the next deck request are given in o-args. See Arguments below 
35 for syntax and full description. 

The cost of retrieving this page (exclusive of telephone system charges) is represented in o-cost. If 
no o-cost is given, the deck cost is included with the user's standard service contract. 
Decks can be cached by the cellular telephone for a period of time. The o-ttl entry indicates the number 
of seconds that the deck can be cached from time of reception. If no o-ttl entry is given, the deck can 
40 only be cached for short periods of time, for example, to implement a back function similar to that of 

most Web browsers. If the value of o-ttl is zero, the deck must not be cached. 



CARD ELEMENTS 



45 [0312] 



50 



55 



card 

card-options 
o-name 
o-next 
o-prev 



::= display-card | choice card | entry- card 

A card is one of three types of card in this embodiment. These are described in the sections below. 
= o-name | o-next | o-prev 
= name= identifier 
= next= destination 
= prev= destination 

All cards can have these options. The optional o-name option gives a name to the card. If a card has 
a name, the card can be referred to by a destination. 

The o-next and o-prev give destinations for the NEXT and PREV keys. If omitted, the defaults are the 
next and previous sequential card in the deck. If o-prev is omitted from the first card, the PREV key 
returns to the deck last visited. If o-next is omitted from the last card, the NEXT key returns to the first 
card of the current deck. However, this default behavior is only a fail-safe: the last card in a deck should 
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always have either an o-next option, or be a choice card where each choice entry indicates a new 
destination. 



DISPLAY CARD 



[0313] 



display-card 

display-header 

display-options 

display-content 

display-footer 



= display-header display-content display-footer 

= <DISPLAY option-list > 

= card-options 

= { softkey }* formatted text 

= </DISPLAY> 

Display cards give information for the user to read. See Formatted Text below for a full description 

of the format of information that can be displayed. 

Softkeys can be described for this card only, see Softkeys below. 



CHOICE CARD 



[0314] 

choice-card 

choice-header 

choice-options 

o-method 

method-type 

entries ::= { choice-entry }+ 
choice-footer 



choice-entry 
entry-options 



group-entry 
group-options 



choice-header display-content { entries } choice-footer 
<CHOICE ol{choice-options} > 
card-options | o-method | o-key | o-default 
method= method-type 
number | list | alpha | group 
{ group-entry { choice-entry }+ )+ 
</CHOICE> 

Choices let user pick one from a list. The initial display content is shown to the user, 
followed by the choices. Each choice can have one line of formatted text (which may 
be wrapped or scrolled by the phone if too long). 

How the choices are displayed and chosen is based on the o-method option. Note that 
this option is a hint only, and can be disregarded by the phone. The number method is 
the default and indicates that the choices are numbered sequentially from one and are 
chosen by pressing the appropriate digit on the keypad. If there are more than nine 
options, the phone may choose some other method of selection. The list method indi- 
cates that the list should be unnumbered and that the user should scroll through the list 
and hit some designated enter key to choose an entry. The alpha method is like list, 
only it is an indication that the text of the entries should be used to aid selection if at all 
possible. In this case, the entries are assumed to be alphabetically sorted. The group 
method is described in more detail below. 

The o-key option indicates, if present, the key of an argument to be added to the argu- 
ment list. See Arguments below for more information. The value of the argument comes 
from the choice entry; see below. The o-default option indicates the default value if the 
user just hit ENTER. See o-default under Entry Card below for more information. 
::= <CE ol(entry-options) > formatted-line 
::= action-options | o-value 

Each choice has text displayed to the user. If the action-options are given, the indicated 
action is performed if the choice is made. If the o-value option is present, it supplies the 
value to the argument identified with the o-key option in the choice header. If no o- value 
is given, the text of the entry is used (without any formatting) as the argument value. 
::= <GE ol(group-options) > 
::= label= value 

If the group method is used, the choices are divided into a number of groups. Each 
group is headed by a group-entry, which, via the label option, gives a short name to the 
group. The phone can then give the user a hierarchial interface for choosing among a 
large number of choices. The text of the label should be limited to eight characters and 
may be truncated by the phone. 
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ENTRY CARD 



[0315] 



entry-card 
entry-header 
entry-options 
entry-footer 



o-format 
format-hint 



= entry-header display-content entry- footer 
<ENTRY ol(entry-options) > 
card-options | o-format | o-key | o-default 
</ENTRY> 

Entries let the user enter a value. The display content is shown to the user, followed by an entry line. 
The user's entry is controlled by the format. The o-key option indicates the argument that is being set 
by this entry. The value of the argument are the user's entry. 
::= format= value { ; format-hint } 
::= value 

This option specifies the format for user input entries. The string consists of format control characters 
and static text which is displayed in the input area. Most of the format control characters control what 
data is expected to be keyed in by the user. They are displayed as blanks until the user types into them. 
The format codes are: 



A entry of any alphabetic character 

9 entry of any numeric character 

X entry of any alphabetic or numeric character 

*f allow entry of any number of characters; the next character, f, is one of A, 9 or X and specifies 

what kind of characters can be entered. 
\c display the next character, c, in the entry field; allows display of the formatting characters in the 

entry field. 

Format hints indicate what kind of value is expected. If a format hint is not understood, it is 
ignored. Currently defined format hints are: 

text text is expected to be text, use special input techniques; generally follows *A or *X 

mail-reply like text, but expected text is for an e-mail message or page; may affect input 
algorithm 

address-list entry is a list of e-mail addresses 



o-default ::= default= value 

The o-default option supplies a value that is used if the user simply hits NEXT. If no default value is 
given, then the user must supply a value. 



FORMATTED TEXT 



[0316] 



formatted-text 
formatted-line 
text-line 



text-format 



alignment-format 



= { { flow-image } { line-format } text-line)* 
= text-line 

= { text | image | text-format | alignment-format }* 
Formatted text is what is shown to the user in most cards. Formatted lines are used for choice 
entries. 

::= <B> | <l> | <BL> 
::= </B> | <l> | <BL> 

The format codes control Bold, Italic and Blinking. The slash versions cancel the formatting. Unlike 
HTML, these needn't be strictly nested and over application and over cancellation are tolerated. 
Formatted-text and formatted-line elements start in plain mode (no bold, italic, or blinking). 
::= <CENTER> | <BOLD> | <TAB> 

The alignment codes specify how parts of a line are to be laid out. The text following the alignment 
code is either centered or right justified on the same line as the other text. The text or image 
following the code is considered to be all text up to the next alignment code or line break. All lines 
start implicitly aligned left. Note that these do not include an implicit line break so that one can 
have both left and right justified text on a single line. If there is too much text and not enough room 
on the line then, if in wrap mode, the non-fitting text is moved to the next line and aligned the same 
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way. If in line mode, the line may end up running together with two spaces between the left, center, 
and right justified segments. 

The tab code is used to create aligned columns. Rather than tab to specific character positions, 
the tab code separates the text for each column. The width of the column is determined by the 
maximal width of the text (or images) in each line. The extent of the columns is from the first line 
with tab codes through the last contiguous line with tab codes. Some lines may have fewer tab 
codes than others, in which case they are assumed to have no text for the extra columns, 
line-format ::= <WRAP> | <LINE> 

::= <BR> 

Multiple lines of text are separated by the <BR> code. If a line is too long to fit on the screen and, 
if in wrap mode, the line is word wrapped onto multiple lines. If in line mode, the line is left as one 
line and is scrolled horizontally. Formatted-text and formatted-line elements start in wrap mode 
and may be changed with either the <WRAP> or <LINE> codes. These codes are an implicit line 
break. 



IMAGES 



[0317] 



image 

flow-image 

image-options 

flow-image-options 

inline-data 



o-source 



o-flow 



<IMAGE ol(image-options) > 
ONLINE ol(image-options) > inline-data </INLINE> 
OMAGE ol(flow-image-options) > 
ONLINE ol(flow-image-options) > inline-data </INLINE> 
o-source 

image-options | o-flow 
ASCIIB5 encoding of image data 
mages are treated as large words and, by default, are simply displayed as part of the text. Flow- 
mages have a flow option that causes them to be treated differently. The image data is stored 
in a separate data stream as identified by the source option. 

nline images are treated identically, only the data is part of the current data stream. ASCII85 is 
a standard way of encoding binary data in printable ASCII, whereby each four bytes of data is 
encoded in five characters. Note that TIL only uses inline images, and uses a different encoding. 
::= src= location 

This option specifies the location of the source for images. 
::= flow= { left | right} 

This option controls the alignment of flow-images. The option specifies that the image is flush 
left or flush right with the screen. Subsequent lines of text flow in the remaining right or left hand 
space. 



SOFTKEYS 



[0318] 

softkey ::= <SOFTKEY ol(softkey-options) > 

softkey-options ::= o-label | o-button | action-options 

Softkeys supply definitions for two buttons known as SOFT-L and SOFT-R. They do not show up 
in the normal text and graphics area displayed to the user, but on a separate line for soft key labels. 
(Note: in some implementations, where screen real estate is scarce, this label line may get used 
for normal text and graphics display when there are no softkeys defined on the current card). 
When the softkey is pressed, the indicated action takes place. 

o-button ::= button= side 

side ::= left | right 

o-label ::= label= value 

The button option specifies which physical key the softkey applies to. The label option is the text 
that is displayed on screen for that key. The phone may truncate the label. It is suggested that labels 
be fewer than eight characters. 

Softkeys can be specified both for the deck as a whole and per card. When specified for the deck 
(after the deck- header, but before the first card) they remain in effect for the entire deck. When 
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specified for a card (at the beginning of the formatted-text for the card), they temporarily override 
any deck softkeys while the card is visible. 

Note that the override is done independently for the two keys (a card can override one softkey, but 
not the other). To override a deck softkey with no softkey (in effect, to remove a softkey for the 
duration of a card) use a softkey with no label and no action. 



SYNTAX: OPTIONS 



[0319] Many of the syntactic elements of PIDL have option lists associated with them. Options refine the operation 
of the elements they are part of. Unless otherwise noted, options do not nest, even when the same option is given in 
two nested elements. Options that are not defined for an element are ignored, even if valid for an enclosing element. 



ol(valid-option) ::= { blank-space valid-option }* {blank-spaces } 
option-list ::= ol(option) 

option ::= key = value 

key ::= identifier 

value ::= plain-text 

::="{text}" 

An option list contains zero or more options. Each option is separated by blank-space (required!) 
and optionally followed by blank-space. In the syntax diagrams, option lists are shown as: o\(valid- 
option) where valid-option is replaced with an element that defines the possible options in this con- 
text, ol is a generic syntactic description of option-lists. 

Each option is a key and a value. They may be given in any order within the list of options. The key 
is always an alpha-numeric name that is case insensitive. The value, if it is composed of only alpha- 
numeric characters, may appear directly after the equals sign. Otherwise, the value must be quoted. 
In quotes, blank-space is treated literally and is considered part of the value. 
In the syntax diagrams, the possible values for various options are specified without quotes. How- 
ever, quotes are always acceptable around an option value. 

Unlike almost all other syntactic elements, blank space is not permitted between the key and the 
equals sign or between the equals sign and the value. 

Many options have a more restricted set of possible values than represented by the above syntax. 
See the individual options for details. 

DESTINATIONS 



[0320] 

destination ::= location { ; animation } 

::= card-loc { ; animation } 
::= stack-operation { ; animation } 

location ::= full-loc | partial-loc | relative-loc 

full-loc ::= : service-id / deck-path 

::= : service-host / deck-path 

partial-loc ::=/ deck-path 

relative-loc {■■/}* deck-path 

card-loc ::= # identifier 

deck-path ::= plain-text { / plain-text }* 

service-id ::= % plain-text 

service-host ::= plain-text 

Destinations are used in some options to indicate the next, or previous deck or card to show. A 
deck is specified either with a full location (service-id and deck-path), just a deck-path (in which 
case the service is the same as the current deck's service), or a relative deck-path. In the later case, 
the last component of the current deck- path is removed, (and one additional component for each ../ 
in the relative deck-path), and the deck-path appended. 
A particular card can be a destination and is specified by a card-loc element. 

stack-operation ::= + card-loc 



In addition to the normal history list of where a user has been that is kept by a phone, the phone 
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animation 



also keeps a short stack of locations. Using a plus sign form causes the current location (deck and 
card, and location in the history list, and animation used) to be pushed on the stack before going 
to the new card. Using the minus sign form causes a return to the location on the top of the stack, 
and the history list to be pruned back to the saved point. If no animation is given, the inverse ani- 
mation is used. The stack is popped. 
slideN | slides 
slideW | slideE 
slideSW | slideNE 
slideSE | slideNW 
flipV 
flipH 
fade 
none 

The optional animation argument indicates what form of screen animation, if available, is to be used 
when going to the destination. The animation is remembered with the destination in the history and 
destination stack. If the user moves to a destination via a 'go' or 'next' operation, then the animation 
is performed. If the user moves to a destination via a 'prev' or 'pop' operation, the reverse animation 
associated with the current location is performed. 



ACTIONS 



[0321] Choice entries and soft keys can specify actions to be performed when the user selects the choice or softkey. 
action-options ::= o-args | o-call | o-page 



o-go ::= go= destination 
o-call ::= call= value 

The go operation indicates that the destination should be moved. 



ARGUMENT PROCESSING 



[0322] Each time a deck is requested, arguments may be passed along with the request. 

These arguments may be used by the service end to compute a deck specific for the user rather than just return a pre- 
written deck. 

Arguments are built-up as the user traverses the deck. Each argument is a key-value pair. While arguments superficially 
look like options, these two entities are quite distinct: Options are a part of PIDL and affect the operation of the phone. 
Arguments are information gathered by the phone and returned to the service. Neither PIDL nor the phone understands 
the arguments beyond their basic syntactic structure. 

Arguments come from three places: Choice cards, Entry cards, and the args option. 

Each of these specifies a key-value pair that is added to a buffer of arguments to be sent. In the case of the args option, 
multiple arguments may be specified. When an argument key-value pair is added to the argument buffer, if the key is 
already present in the buffer, its value is replaced. 



o-args 

argument-list 
arg-key-value 
arg-key 
arg-value 



o-key 
o-value 



= args= arg-list 

= arg-key-value { { & | ; } key-value }* 
= arg-key = arg-value 
= identifier 
= plain-text 

Note: The entire o-args element is actually the value of an option. If it has more than one arg-key- 
value it will need to be in quotes. Since the ampersand (&) and semi-colon (;) are used as key-value 
pair separators, these characters cannot be part of argument values. 



::= key= arg-key 
::= value= arg-value 

These options are used in choice and entry cards to specify the key and value for the arguments 
those cards set. 
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BASIC ELEMENTS 



[0323] 



alpha 
numeric 
alpha-numeric 
hex 

blank-space 

space 

tab 

new-line 



word 
identifier 
integer 
text 



plain-text safe 



any alphabetic character 
any digit 
alpha | numeric 

numeric | any letter A through F, either case 
{ space | tab | new-line }+ 
the space character 
the tab character 
the carriage return character 
the line feed character 
the sequence carriage return, line feed 
{ alpha-numeric }+ 
alpha { alpha-numeric }* 
{ + | - } { numeric }+ 

any 7-bit ASCII character except <, >, ", or & 
> | < | " | Samp; 
|   

::= any ISO-Latin-1 named entity 
::= &# hex hex ; 

In text, runs of blank-space are treated as single spaces and my be used as point for word wrapping. 
::= { alpha | numeric | safe }* ::= $ | - 1 - 1 @ | . | & | 1 | * | , 



TIL ENCODING 



[0324] Except where noted, TIL is identical to PIDL in structure. To translate PIDL to TIL several steps are concep- 
tually needed (these may be done in one pass by a translator): 



1 . Escape characters with the high bit set. 

2. Compress or remove all blank space where possible. 

3. Tokenize comment elements with a single byte with the high bit set. 

4. Inline images. 



Fundamentally, TIL is just PIDL with certain common character sequences replaced by single bytes with the high-bit 
set. The first two steps above support this. Additionally, images are further compacted by including them inline in a 
dense format. 

The tokenizing follows the encoding given in the table below. Note that for purposes of element separation, the tokens 
that represent option key identifiers (with the equal sign) can be considered to include all preceding blank space. 
Similarly, the tokens that represent option values can be considered to include all following blank space. 



<PIDL> 


90 


args= 


CO 


alpha 


EO 


</PIDL> 


91 


button= 


C1 


center 


E1 


<DISPLAY> 


92 


call= 


C2 


fade 


E2 


</DISPLAY> 


93 


cost= 


C3 


flipH 


E3 


<CHOICE> 


94 


defaults 


C4 


flipV 


E4 


</CHOICE> 


95 


flow= 


C5 


group 


E5 


<ENTRY> 


96 


format= 


C6 


inline 


E6 


</ENTRY> 


97 


go= 


C7 


left 


E7 


<CE 


AO 


key= 


C8 


list 


E8 


<GE 


A1 


label= 


C9 


none 


E9 


<IMAGE 


A2 


method= 


CA 


number 


EA 
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(continued) 



<INLINE 


A3 


name= 


CB 


right 


EB 


<SOFTKEY 


A4 


next= 


CC 


slideE 


EC 


<B> 


BO 


page= 


CD 


slideN 


ED 


</B> 


B1 


prev= 


CE 


slideNE 


EE 


<l> 


B2 


src= 


CF 


slideNW 


EF 


</l> 


B3 


ttl= 


DO 


slides 


FO 


<BL> 


B4 


value= 


D1 


slideSE 


F1 


</BL> 


B5 






slideSW 


F2 


<CENTER> 


B6 






slideW 


F3 


<RIGHT> 


B7 










<WRAP> 


B8 










<LINE> 


B9 










<BR> 


BA 
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APPENDIX II 

A COMPUTER PROGRAM TO GENERATE A LETTER FREQUENCY TABLE FOR USE IN THE PREDICTIVE DATA 
ENTRY PROCESS Unpublished © 1995 Libris, Inc. 

[0325] 

/* This program opens a text file selected by the 

user, generates the frequency table for that file, 
and then writes the frequency table to another 
file also selected by the user. 

*/ 

#include <stdio.h> 
#include <string.h> 
#include <console.h> 
#include <assert.h> 

typedef unsigned char byte; 

typedef byte triplet [3]; 

typedef byte tristorage [27] [27] [27] ; 

IncrementTrigram (triplet t, tristorage trigrams) 
{ 

byte * pb; 
assert (t [O] < 27) ; 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

pb = &trigrams [t [O] ] [t [1] ] [t [2] ] ; 
if (*pb < 255) *pb = *pb + 1; 
return *pb; 

} 

StoreTrigramValue (triplet t, tristorage trigrams, byte 
value) 

{ 
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assert (t [0] < 27) ; 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

trigrams [t [O] ] [t[l]] [t [2] ] = value; 

} 

byte FetchTrigramvalue (triplet t, tristorage trigrams) 
{ 

assert (t [0] < 27) ; . 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

return trigrams [t [0] ] [t [1] ] [t [2] ] ; 

} 

byte DumpTrigram (triplet t, tristorage trigrams) 
{ 

byte value; 
assert (t [O] < 27) ; 
assert (t [1] < 27) ; 
assert (t [2] < 27) ; 

value = FetchTrigramValue (t , trigrams); 
if (value ! = O) 

{ 

printf ("%c%c%c = t [O] + 'a', t[l] + 'a', t[2] 

'a') ; 

if (value == 255) printf ("***") ; 
else printf ("%3d" , value); 

} 

return value ; 
} 

int IdFromChar (short c) 
{ 

c = tolower (c) ; 

if (c < 'a' || c > 'z') return 26; 
return c - ' a' ; 
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} 

AddChar (tri storage trigrams, triplet t, byte b) 
{ 

byte value; 
unsigned short r; 

assert (b <= 26 ) ; 

if (b == 26) { t[0] = ttl] = t[2] = 26; return; } 

t [0] = t [1] ; 
t [1] = t [2] ; 
t[2] = b; 

value = FetchTrigramValue (t, trigrams); 
if (value == 255) return; 

#if 0 

if (value > 64) { 
r = Random ( ) ; 

if (value > 192 && r & OxEOOO) return; 
else if (value > 128 && r & OxCOOO) return; 
else if (value > 64 && r & 0x8000) return; 

} 

#endif 

StoreTrigramValue (t, trigrams, value + 1) ; 



DumpTrigrams (tristorage trigrams) 
{ 

int i, j, k; 
int x; 
triplet t; 
x = O; 

for (i = 0; i < 2 6; ++i) 
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for (j = 0; j < 26; ++j) 
for (k = 0; k < 26; ++k) 
{ 

byte value; 
t[0] = i; 
t[l] = j; 
t[2] = k; 



value = DumpTrigram{t, trigrams) ; 

if (value == 0) continue; 
if (++x == 6) { 

printf ("\n") ; x = 0; 

} 

else 

printf (" ") ; 

} 

} 

OSErr BuildTrigram (short refNum, tristorage trigrams) 
{ 

OSErr err; 
triplet t; 

t [0] = t [1] = t [2] = 26; 

while (true) 

{ 

long count = 80; 
char buf [8 0] ; 
int i ; 

err = FSRead (refNum, icount, buf ) ; 
if (count == 0) return err; 
for (i = 0; i < count; ++i) { 

AddChar (trigrams, t, IdFromChar (buf [i] ) ) ; 
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} 

if (err) return err; 

} 

return 0; 

} 

Handle OpenTrigrams ( void) 
{ 

OSErr err; 
OSType type; 
StandardFileReply reply 
short refNum ; 
short id; 
Handle h; 
Str63 name; 
tristorage *trigrams; 

type = 'TEXT' ; 

StandardGet File (nil, i, &type, &reply) ; 

if ( "reply . sf Good) return nil; 

err = FSpOpenDF (fcreply . sf File, fsCurPerm, &re 

if (err) return nil; 

memcpy (name, reply . sf File . name , sizeof (name) ) 
h = NewHandle (sizeof (tristorage) ) ; 

HLock (h) ; 

trigrams = (tristorage *) (*h) ; 

memset (*trigrams, 0, sizeof (tristorage) ) ; 

BuildTrigram (refNum, *trigrams) ; 
FSClose (refNum) ; 
DumpTrigrams (* trigrams) ; 
HUnlock (h) ; 
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type = ' rsrc ' ; 

StandardGetFile (nil, 1, &type, &reply) ; 
if (! reply . sf Good) return; 

refNura = FSpOpenResFile (&reply . sfFile, f sCurPerm) ; 
if (refNum == -1) return; 
UseResFile (refNum) ; 



id - UniquellD ( ' smrt ' ) ; 
15 //id = 128; 

AddRe source (h, ' smrt ' , id, name) ,- 
UpdateResFile (refNum) ; 
FSClose (refNum) ; 

20 

return h; 

} 



25 main ( ) 

{ 

OSErr err; 
30 Handle h; 



cshow (stdout) ; 
TEInit () ; 
InitDialogs (OL) ; 
InitCursor ( ) ; 
h = OpenTrigrams ( ) ; 
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Claims 



1. A method, implemented in a network node (500, 743) coupled to a wireless telecommunications network (110, 
50 111) and to a wireline computer network (120, 130, 140), to enable respective pocket sized mobile two-way data 

capable wireless communication devices (100, 101) to have interactive two-way communication with an applica- 
tion, the method comprising:- 

receiving over the wireless telecommunications network (110, 111) a request from a said mobile device to 
55 execute an application on a server (121, 131, 141) on the wireline computer network (120, 130, 140); 

sending the request over the wireline computer network to the server to access said application; 

characterised by 
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receiving a response over the wireline computer network according to the execution of said accessed appli- 
cation, the response consisting of information to be interpreted by the mobile device and whereby an interactive 
user interface is generated therefrom and whereby another request is generated therefrom to said or another 
server according to the use made of that generated user interface; and 
s sending the response to said a mobile device over the wireless telecommunications network. 

2. A method as claimed in claim 1 wherein a group of one or more related interactive user interfaces is generated 
from said information. 

10 3. A method as claimed in claim 2 wherein the or each interactive user interface comprises one or more screen 
displays (300, 304, 306, 308) on the mobile communication device (100, 101). 

4. A method as claimed in claim 2 or 3 further comprising operating the network node (500, 743) to generate the 
group dynamically in response to the request. 

15 

5. A method as claimed in any one of claims 2 to 4 wherein one or more user interfaces of the group specify one or 
more tasks to be performed on the mobile communication device (100, 101). 

6. A method as claimed in any preceding claim further comprising converting the response from a first language used 
20 on the wireline computer network (120, 130, 140) to a second language used on the wireless telecommunications 

network (110, 111). 

7. A method as claimed in claim 6 wherein the response comprises a mark-up language document. 

25 8. A method as claimed in claim 6 or 7 wherein the second language is a distilled form of the first language, and 
wherein sending the translated response to the mobile communication device (100, 101) comprises sending the 
response to the mobile communication device (100, 101) in the second language over the wireless telecommuni- 
cations network (110, 111) such that the response sent to the mobile communication device (100, 101) is a com- 
pressed form of the response received by the network node (500, 743) from a server on the wireline computer 

30 network (120, 130, 140). 

9. A method as claimed in any preceding claim wherein the network node (500, 743) comprises a gateway server to 
couple the wireless telecommunications network (110, 111) to the wireline data network. 

35 10. A method as claimed in any one of claims 1 to 8 wherein the network node (500, 743) comprises a proxy server 
to proxy requests from the mobile communication device (100, 101) to remote servers on the wireline computer 
network (120, 130, 140). 

1 1 . A method as claimed in claim 1 further comprising:- 

40 

operating the network node (500, 743) to communicate with the mobile communication device (100, 101) over 
the wireless telecommunications network (110, 111, 112) using a first protocol; and 

operating the network node (500, 743) to communicate over the wireline computer network (120, 130, 140) 
using a second protocol different from the first protocol. 

45 

12. A method as claimed in any preceding claim wherein the network node (500, 743) comprises an HTTP server. 

13. A method as claimed in claim 12 wherein the network node (500, 743) comprises a UDP module in addition to the 
HTTP server, and wherein the HTTP server uses the UDP module to communicate data with the wireless tele- 

50 communications network (110, 111). 

14. A method as claimed in any preceding claim further comprising operating the network node (500, 743) to control 
access to resources on the wireline computer network (120, 130, 140) by the mobile communication device (100, 
101). 

55 

15. A method as claimed in claim 14 wherein operating the network node (500, 743) to control access to resources 
on the wireline computer network (120, 130, 140) comprises operating the network node (500, 743) to authorize 
requests by the mobile device (100, 101) . 
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16. A method as claimed in any preceding claim wherein the mobile communication device includes a client module 
(702) that requires only lightweight memory and processing power to operate. 

17. A method as claimed in any preceding claim further comprising controlling access by the mobile devices to pay- 
s ment-based services on the wireline computer network (120, 130, 140), including collecting transaction and billing 

information associated with providing resources on the wireline computer network (120, 130, 140) to the mobile 
devices. 

18. A network node (500, 743) comprising:- 

10 

a first communication interface (748, 1202) to communicate with respective pocket sized mobile two-way data 
capable wireless communication devices (100, 101) over a wireless telecommunications network (110, 111); 
a second communication interface (1203) capable of communication with a server (121, 131, 141) over a 
wireline computer network (120, 130, 140); and 
15 a processor (1204) coupled to the first communication interface and the second communication interface to 

execute a process, the process including:- 

receiving over the wireless telecommunications network a request from a said mobile device to execute 
an application on a said server on the wireline computer network (120, 130, 140); 
20 sending the request over the wireline computer network to said server to access said application; char- 

acterised by 

receiving a response over the wireline computer network according to the execution of said accessed 
application, the response consisting of information to be interpreted by the mobile device and whereby 
an interactive user interface is generated therefrom and whereby another request is generated therefrom 
25 to said or another server according to the use made of that generated user interface; and 

sending the response to said a mobile device over the wireless telecommunications network. 

19. A network node as claimed in claim 18 wherein a group of one or more related interactive user interfaces is gen- 
erated from said information. 

30 

20. A network node as claimed in claim 19 wherein the or each interactive user interface comprises one or more screen 
displays (300, 304, 306, 308) on the mobile communication device (100, 101). 

21 . A network node as claimed in claim 1 9 or 20 further comprising generating the group dynamically in response to 
35 the request. 

22. A network node as claimed in one of claims 19 to 21 wherein one or more user interfaces of the group specify one 
or more tasks to be performed on the mobile communication device (100, 101). 

40 23. A network node as claimed in any one of claims 1 8 to 22 further comprising converting the response from a first 
language used on the wireline computer network (120, 130, 140) to a second language used on the wireless 
telecommunications network (110, 111). 

24. A network node as claimed in claim 23 wherein the response comprises a mark-up language document. 

45 

25. A network node as claimed in claim 23 or 24 wherein the second language is a distilled form of the first language, 
and wherein sending the translated response to the mobile communication device (100, 101) comprises sending 
the response to the mobile communication device (100, 101) in the second language over the wireless telecom- 
munications network (110, 111) such that the response sent to the mobile communication device (100, 101) is a 

50 compressed form of the response received by the network node (500, 743) from a server on the wireline computer 

network (120, 130, 140). 

26. A network node as claimed in anyone of claims 18 to 25 wherein the network node (500, 743) comprises a gateway 
server to couple the wireless telecommunications network (110, 111) to the wireline data network. 

55 

27. A network node as claimed in any one of claims 18 to 25 wherein the network node (500, 743) comprises a proxy 
server to proxy requests from the mobile communication device (100, 101) to remote servers on the wireline com- 
puter network (120, 130, 140). 
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28. A network node as claimed in claim 18 further comprising:- 

operating the network node (500, 743) to communicate with the mobile communication device (100, 101) over 
the wireless telecommunications network (110, 111, 112) using a first protocol; and 
s operating the network node (500, 743) to communicate over the wireline computer network (120, 130, 140) 

using a second protocol different from the first protocol. 

29. A network node as claimed in any one of claims 1 8 to 28 wherein the network node (500, 743) comprises an HTTP 
server. 

10 

30. A network node as claimed in claim 29 wherein the network node (500, 743) comprises a UDP module in addition 
to the HTTP server, and wherein the HTTP server uses the UDP module to communicate data with the wireless 
telecommunications network (110, 111). 

15 31. A network node as claimed in anyone of claims 18 to 30 further comprising controlling access to resources on the 
wireline computer network (120, 130, 140) by the mobile communication device (100, 101). 

32. A network node as claimed in claim 31 wherein operating the network node (500, 743) to control access to resources 
on the wireline computer network (120, 130, 140) comprises operating the network node (500, 743) to authorize 

20 requests by the mobile device (100, 101). 

33. A network node as claimed in any one of claims 18 to 32 wherein the mobile communication device includes a 
client module (702) that requires only lightweight memory and processing power to operate. 

25 34. A network node as claimed in any one of claims 18 to 33 further comprising controlling access by the mobile 
devices to payment-based services on the wireline computer network (120, 130, 140), including collecting trans- 
action and billing information associated with providing resources on the wireline computer network (120, 130, 
140) to the mobile devices. 

30 

Patentanspruche 

1. Verfahren, das in einem Netzwerkknoten (500, 743) implementiert ist, der mit einem drahtlosen Telekommunika- 
tionsnetzwerk (110, 111) und mit einem drahtgebundenen Computernetzwerk (120, 130, 140) gekoppelt ist, zum 

35 Ermoglichen, dass jeweilige zu einer drahtlosen Kommunikation fahige mobile Vorrichtungen (100, 101) in Ta- 

schengroRe fur Zweiwegedaten eine interaktive Zweiwegekommunikation mit einer Anwendung haben, wobei das 
Verfahren folgendes aufweist: 

uber das drahtlose Telekommunikationsnetzwerk (110, 111) Empfangen einer Anfrage von der mobilen Vor- 
40 richtung, eine Anwendung auf einem Server (121, 131, 141) auf dem drahtgebundenen Computernetzwerk 

(120, 130, 140) auszufuhren; 

Senden einer Anfrage Ober das drahtgebundene Computernetzwerk zu dem Server, urn auf die Anwendung 
zuzugreifen; 

45 gekennzeichnet durch 

Empfangen einer Antwort uber das drahtgebundene Computemetz gemaft der Ausfuhrung der Anwendung, 
auf die zugegriffen ist, wobei die Antwort aus durch die mobile Vorrichtung zu interpretierender Information 
besteht und wobei daraus eine interaktive Anwenderschnittstelle erzeugt wird und wobei daraus eine weitere 
so Anfrage zu dem oderzu einem anderen Server gemaft der von diesererzeugten Anwenderschnittstelle durch- 

gefuhrten Verwendung erzeugt wird; und 

Senden der Antwort zu der mobilen Vorrichtung uber das drahtlose Telekommunikationsnetzwerk. 

2. Verfahren nach Anspruch 1 , wobei eine Gruppe von einer oder mehreren zugehorigen interaktiven Anwender- 
55 schnittstellen aus der Information erzeugt wird. 

3. Verfahren nach Anspruch 2, wobei die oder jede interaktive Anwenderschnittstelle eine oder mehrere Bildschirm- 
anzeigen (300, 304, 306, 308) an der mobilen Kommunikationsvorrichtung (100, 101) aufweist. 
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4. Verfahren nach Anspruch 2 Oder 3, das weiterhin ein Betreiben des Netzwerkknotens (500, 743) aufweist, um die 
Gruppe in Antwort auf die Anfrage dynamisch zu erzeugen. 

5. Verfahren nach einem der Anspruche 2 bis 4, wobei eine Oder mehrere Anwenderschnittstellen der Gruppe eine 
s oder mehrere Aufgaben spezifizieren, um auf der mobilen Kommunikationsvorrichtung (100, 101) durchgefuhrt zu 

werden. 

6. Verfahren nach einem der vorangehenden Anspruche, das weiterhin ein Umwandeln der Antwort aus einerersten 
Sprache, die auf dem drahtgebundenen Computernetzwerk (120, 130, 140) verwendet wird, in eine zweite Spra- 

10 che, die auf dem drahtlosen Telekommunikationsnetzwerk (110, 111) verwendet wird, aufweist. 

7. Verfahren nach Anspruch 6, wobei die Antwort ein Markup-Language-Dokument aufweist. 

8. Verfahren nach Anspruch 6 oder 7, wobei die zweite Sprache eine destillierte Form der ersten Sprache ist und 
15 wobei ein Senden der ubersetzten Antwort zu der mobilen Kommunikationsvorrichtung (100, 101) ein Senden der 

Antwort zu der mobilen Kommunikationsvorrichtung (100, 101) in derzweiten Sprache uber das drahtlose Tele- 
kommunikationsnetzwerk (110, 111) aufweist, so dass die zu der mobilen Kommunikationsvorrichtung (100, 101) 
gesendete Antwort eine komprimierte Form der durch den Netzwerkknoten (500, 743) von einem Server an dem 
drahtgebundenen Computernetzwerk (120, 130, 140) empfangenen: Antwort ist. 

20 

9. Verfahren nach einem der vorangehenden Anspruche, wobei der Netzwerkknoten (500, 743) einen Gateway- 
Server aufweist, um das drahtlose Telekommunikationsnetzwerk (110, 111) mit dem drahtgebundenen Datennetz- 
werk zu koppeln. 

25 10. Verfahren nach einem der Anspruche 1 bis 8, wobei der Netzwerkknoten (500, 743) einen Proxy-Server aufweist, 
um Anfragen von der mobilen Kommunikationsvorrichtung (100, 101) zu entfernten Servern auf dem drahtgebun- 
denen Computernetzwerk (120, 130, 140) zu vertreten bzw. zu bevollmachtigen. 

11. Verfahren nach Anspruch 1, das weiterhin folgendes aufweist: 

30 

Betreiben des Netzwerkknotens (500, 743), um mit der mobilen Kommunikationsvorrichtung (100, 101) Ober 
das drahtlose Telekommunikationsnetzwerk (110, 111, 112)unterVerwendung eines ersten Protokollszu kom- 
munizieren; und 

Betreiben des Netzwerkknotens (500, 743), um uber das drahtgebundene Computernetzwerk (120, 130, 140) 
35 unter Verwendung eines: zweiten Protokolls zu kommunizieren, das unterschiedlich von dem ersten Protokoll 

ist. 

12. Verfahren nach einem der vorangehenden Anspruche, wobei der Netzwerkknoten (500, 743) einen HTTP-Server 
aufweist. 

40 

13. Verfahren nach Anspruch 12, wobei der Netzwerkknoten (500, 743) ein UDP-Modul zusatzlich zu dem HTTP-Ser- 
ver aufweist und wobei der HTTP-Server das UDP-Modul verwendet, um Daten mit dem drahtlosen Telekommu- 
nikationsnetzwerk (110, 111) zu kommunizieren. 

45 14. Verfahren nach einem der vorangehenden Anspruche, das weiterhin ein Betreiben des Netzwerkknotens (500, 
743) aufweist, um einen Zugriff auf Betriebsmittel auf dem drahtgebundenen Computernetzwerk (120, 130, 140) 
durch die mobile Kommunikationsvorrichtung (100, 101) zu steuern. 

15. Verfahren nach Anspruch 14, wobei ein Betreiben des Netzwerkknotens (500, 743) zum Steuern eines Zugriffs 
so auf Betriebsmittel auf dem drahtgebundenen Computernetzwerk (120, 130, 140) ein Betreiben des Netzwerkkno- 
tens (500, 743) zum Autorisieren von Anfragen durch die mobile Vonichtung (100, 101) aufweist. 

16. Verfahren nach einem der vorangehenden Anspruche, wobei die mobile Kommunikationsvorrichtung ein Client- 
Modul (702) enthalt, das nur eine leichtgewichtige Speicher- und Verarbeitungsenergie zum Arbeiten erfordert. 

55 

17. Verfahren nach einem der vorangehenden Anspruche, das weiterhin ein Steuern eines Zugriffs durch die mobilen 
Vorrichtung auf bezahlungsbasierende Dienste auf dem drahtgebundenen Computernetzwerk (120, 130, 140), 
einschliefilich eines Sammelns von Transaktions- und Berechnungsinformation, die zu einem Bereitstellen von 
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Betriebsmitteln auf dem drahtgebundenen Computemetzwerk (120, 130, 140) zu den mobilen Vorrichtungen ge- 
hort, aufweist. 

18. Netzwerkknoten (500, 743), derfolgendes aufweist: 

5 

eine erste Kommunikationsschnittstelle (748, 1202) zum Kommunizieren mit zu einer drahtlosen Kommuni- 
kation fahigen mobilen Vorrichtungen (100, 101) in TaschengroRe fur Zweiwegedaten uber ein drahtloses 
Telekommunikationsnetzwerk (110, 111); 

eine zweite Kommunikationsschnittstelle (1203), die zu einer Kommunikation mit einem Server (121, 131, 
10 141) uber ein drahtgebundenes Computemetzwerk (120, 130, 140) fahig ist; und 

einen Prozessor (1204), der mit der ersten Kommunikationsschnittstelle und der zweiten Kommunikations- 
schnittstelle gekoppelt ist, urn einen Prozess auszufuhren, wobei der Prozess folgendes enthalt: 

uber das drahtlose Telekommunikationsnetzwerk Empfangen einer Anfrage von der mobilen Vorrichtung, 
15 urn eine Anwendung auszufuhren, auf einem Server auf dem drahtgebundenen Computemetzwerk (120, 

130, 140); 

Senden der Anfrage uber das drahtgebundene Computemetzwerk zu dem Server, urn auf die Anwendung 
zuzugreifen; gekennzeichnet durch 

Empfangen einer Antwort uber das drahtgebundene Computemetzwerk gemali der Ausfuhrung der An- 
20 wendung, auf die zugegriffen ist, wobei die Antwort aus durch die mobile Vorrichtung zu interpretierender 

Information besteht und wobei daraus eine interaktive Anwenderschnittstelle erzeugt wird und wobei dar- 
aus eine weitere Anfrage zu dem Oder einem weiteren Server gemaB der von der erzeugten Anwender- 
schnittstelle gemachten bzw. durchgefuhrten Anwendung erzeugt wird; und 
Senden der Antwort zu der mobilen Vorrichtung uber das drahtlose Telekommunikationsnetzwerk. 

25 

19. Netzwerkknoten nach Anspruch 18, wobei eine Gruppe von einer Oder mehreren zugehorigen interaktiven An- 
wenderschnittstellen aus der Information erzeugt wird. 

20. Netzwerkknoten nach Anspruch 19, wobei die! oder jede interaktive Anwenderschnittstelle eine oder mehrere 
30 Bildschirmanzeigen (300, 304, 306, 308) an der mobilen Kommunikationsvorrichtung (100, 101) aufweist. 

21 . Netzwerkknoten nach Anspruch 1 9 oder 20, der weiterhin ein dynamisches Erzeugen der Gruppe in Antwort auf 
die Anfrage aufweist. 

35 22. Netzwerkknoten nach einem der Anspruche 1 9 bis 21 , wobei eine oder mehrere Anwenderschnittstellen der Grup- 
pe eine oder mehrere Aufgaben spezifizieren, urn auf der mobilen Kommunikationsvorrichtung (100, 101) durch- 
gefuhrt zu werden. 

23. Netzwerkknoten nach einem der Anspruche 1 8 bis 22, der weiterhin ein Umwandeln der Antwort von einer ersten 
40 Sprache, die auf dem drahtgebundenen Computemetzwerk (120, 130, 140) verwendet wird, in eine zweite Spra- 

che, die auf dem drahtlosen Telekommunikationsnetzwerk (110, 111) verwendet wird, aufweist. 

24. Netzwerkknoten nach Anspruch 23, wobei die Antwort ein Markup-Language-Dokument aufweist. 

45 25. Netzwerkknoten nach Anspruch 23 oder 24, wobei die zweite Sprache eine destillierte Form der ersten Sprache 
ist und wobei ein Senden der ubersetzten Antwort zu der mobilen Kommunikationsvorrichtung (100, 101) ein Sen- 
den der Antwort zu der mobilen Kommunikationsvorrichtung (100, 101) in der zweiten Sprache uber das drahtlose 
Telekommunikationsnetzwerk (110, 111) aufweist, so dass die zu der mobilen Kommunikationsvorrichtung (100, 
101) gesendete Antwort eine komprimierte Form der durch den Netzwerkknoten (500, 743) von einem Server auf 

so dem drahtgebundenen Computemetzwerk (120, 130, 140) empfangenen Antwort ist. 

26. Netzwerkknoten nach einem der Anspruche 18 bis 25, wobei der Netzwerkknoten (500, 743) einen Gateway- 
Server aufweist, urn das drahtlose Telekommunikationsnetzwerk (110, 1 1 1 ) mit dem drahtgebundenen Datennetz- 
werk zu koppeln. 

55 

27. Netzwerkknoten nach einem der Anspruche 18 bis 25, wobei der Netzwerkknoten (500, 743) einen Proxy-Server 
aufweist, urn Anfragen von der mobilen Kommunikationsvorrichtung (100, 101) zu entfernten Servern auf dem 
drahtgebundenen Computemetzwerk (120, 130, 140) zu bevollmachtigen bzw. zu vertreten. 
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28. Netzwerkknoten nach Anspruch 18, der weiterhin folgendes aufweist: 

Betreiben des Netzwerkknotens (500, 743) zum Kommunizieren mit der mobilen Kommunikationsvorrichtung 
(100, 101)uberdas drahtlose Telekommunikationsnetzwerk (110, 111, 112) unter Verwendung eines ersten 
s Protokolls; und 

Betreiben des Netzwerkknotens (500, 743) zum Kommunizieren Ober das drahtgebundene Computernetz- 
werk(120, 130, 140) unter Verwendung eines zweiten Protokolls, das unterschiedlich vom ersten Protokoll ist. 

29. Netzwerkknoten nach einem der Anspruche 18 bis 28, wobei der Netzwerkknoten (500, 743) einen HTTP-Server 
10 aufweist. 

30. Netzwerkknoten nach Anspruch 29, wobei der Netzwerkknoten (500, 743) ein UDP-Modul zusatzlich zu dem HT- 
TP-Server aufweist, und wobei der HTTP-Server das UDP-Modul zum Kommunizieren von Daten mit dem draht- 
losen Telekommunikationsnetzwerk (110, 111) verwendet. 

15 

31. Netzwerkknoten nach einem der Anspruche 18 bis 30, der weiterhin ein Steuern eines Zugriffs auf Betriebsmittel 
auf dem drahtgebundenen Computernetzwerk (120, 130, 140) durch die mobile Kommunikationsvorrichtung (100, 
101) aufweist. 

20 32. Netzwerkknoten nach Anspruch 31, wobei ein Betreiben des Netzwerkknotens (500, 743) zum Steuern eines 
Zugriffs auf Betriebsmittel auf dem drahtgebundenen: Computernetzwerk (120, 130, 140) ein Betreiben des Netz- 
werkknotens (500, 743) zum Autorisieren von Anfragen durch die mobile Vorrichtung (100, 101) aufweist. 

33. Netzwerkknoten nach einem der Anspruche 18 bis 32, wobei die mobile Kommunikationsvorrichtung ein Client- 
25 Modul (702) aufweist, das nur eine leichtgewichtige Speicher- und Verarbeitungsenergie zum Arbeiten erfordert. 

34. Netzwerkknoten nach einem der Anspruche 18 bis 33, der weiterhin ein Steuern eines Zugriffs durch die mobilen 
Vorrichtungen auf bezahlungsbasierende Dienste auf dem drahtgebundenen Computernetzwerk (120, 130,140), 
einschliefilich eines Sammelns von Transaktiohs- und Buchungsinformation, die zu einem Bereitstellen von Be- 

30 triebsmitteln auf dem drahtgebundenen Computernetzwerk (120, 130, 140) zu den mobilen Vorrichtungen gehbrt, 

aufweist. 



Revendications 

35 

1. Procede, implements dans un noeud de reseaux (500, 743) couple a un reseau de telecommunications sans fil 
(110, 111) et a un reseau d'ordinateurs cable (120, 130, 140), pour permettre a des dispositifs mobiles de com- 
munication bidirectionnelle sans fil de donnees de dimension de poche respectifs (100, 101) d'avoir une commu- 
nication bidirectionnelle interactive avec une application, le procede comprenant les operations consistant a : 

40 

recevoir sur le reseau de telecommunications sans fil (110, 111) une requete provenant d'un dispositif mobile 
precite pour executer une application sur un serveur (121, 131, 141) sur le reseau d'ordinateurs cable (120, 
130, 140) ; 

envoyer la requete sur le reseau d'ordinateurs cable au serveur pour acceder a ladite application ; 

45 

caracterise par les operations consistant a : 

recevoir une reponse sur le reseau d'ordinateurs cable conformement a I'execution de ladite application ac- 
cedee, la reponse consistant en informations devant etre interpreters par le dispositif mobile et par lequel une 
50 interface utilisateur interactive est generee a partir de celui-ci et par lequel une autre requete est generee a 

partir de celui-ci vers ledit serveur ou un autre serveur conformement a I'utilisation faite de cette interface 
utilisateur generee ; et 

adresser la reponse a un dispositif mobile precite sur le reseau de telecommunications sans fil. 

55 2. Procede selon la revendication 1 , dans lequel un groupe d'une ou plusieurs interfaces utilisateur interactives cor- 
relees est genere a partir desdites informations. 

3. Procede selon la revendication 2, dans lequel I'interface utilisateur interactive ou chaque interface utilisateur in- 
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10 



teractive comprend un ou plusieurs affichages par ecrans (300, 304, 306, 308) sur le dispositif de communication 
mobile (100, 101). 

Precede selon I'une des revendications 2 ou 3, comprenant en outre I'operation consistant a faire fonctionner le 
noeud de reseaux (500, 743) pour generer le groupe dynamiquement en reponse a la requete. 

. Precede selon I'une quelconque des revendications 2 a 4, dans lequel une ou plusieurs interfaces utilisateur du 
groupe specifie une ou plusieurs taches devant etre effectuees sur le dispositif de communication mobile (100, 
101). 

6. Precede selon I'une quelconque des revendications precedentes, comprenant en outre I'operation consistant a 
convertir la reponse d'un premier langage utilise sur le reseau d'ordinateurs cable (120, 130, 140) a un second 
langage utilise sur le reseau de telecommunications sans fil (110, 111). 

15 7. Precede selon la revendication 6, dans lequel la reponse comprend un document en langage balise. 

8. Precede selon I'une des revendications 6 ou 7, dans lequel le second langage est une forme distillee du premier 
langage, et dans lequel I'operation consistant a adresser la reponse traduite au dispositif de communication mobile 
(100, 101) comprend I'operation consistant a adresser la reponse au dispositif de communication mobile (100, 

20 101) dans le second langage sur le reseau de telecommunications sans fil (110, 111) de telle sorte que la reponse 

adressee au dispositif de communication mobile (100, 101) est une forme comprimee de la reponse recue par le 
noeud de reseaux (500, 743) a partir d'un serveur sur le reseau d'ordinateurs cable (120, 130, 140). 

9. Precede selon I'une quelconque des revendications precedentes, dans lequel le noeud de reseaux (500, 743) 
25 comprend un serveur de passerelle pour coupler le reseau de telecommunications sans fil (110, 111) au reseau 

de donnees cable. 

10. Precede selon I'une quelconque des revendications 1 a 8, dans lequel le noeud de reseaux (500, 743) comprend 
un serveur proxy pour mandater des requetes provenant du dispositif de communication mobile (100, 101) a des 

30 serveurs distants sur le reseau d'ordinateurs cable (120, 130, 140). 

11. Precede selon la revendication 1 comprenant en outre les operations consistant a : 

faire fonctionner le noeud de reseaux (500, 743) pour communiquer avec le dispositif de communication mobile 
35 (100, 101) sur le reseau de telecommunications sans fil (110, 111, 112) en utilisant un premier protocole ; et 

faire fonctionner le noeud de reseaux (500, 743) pour communiquer sur le reseau d'ordinateurs cable (120, 
130, 140) en utilisant un second protocole different du premier protocole. 

12. Precede selon I'une quelconque des revendications precedentes, dans lequel le noeud de reseaux (500, 743) 
40 comprend un serveur HTTP. 

13. Precede selon la revendication 12, dans lequel le noeud de reseaux (500, 743) comprend un module UDP en plus 
du serveur HTTP, et dans lequel le serveur HTTP utilise le module UDP pour communiquer des donnees avec le 
reseau de telecommunications sans fil (110, 111). 

45 

14. Precede selon I'une quelconque des revendications precedentes, comprenant en outre I'operation consistant a 
actionner le noeud de reseaux (500, 547) pour controler I'acces a des ressources sur le reseau d'ordinateurs cable 
(120, 130, 140) par le dispositif de communication mobile(100, 101). 

50 15. Precede selon la revendication 14, dans lequel I'actionnement du noeud de reseaux (500, 547) pour controler 
I'acces a des ressources sur le reseau d'ordinateurs cable (120, 1 30, 140) comprend I'operation consistant a faire 
fonctionner le noeud de reseaux (500, 743) pour autoriser des requetes par le dispositif mobile (100, 101). 

16. Precede selon I'une quelconque des revendications precedentes, dans lequel le dispositif de communication mo- 
ss bile comprend un module de client (702) qui necessite seulement une memoire et une puissance de calcul legeres 

pour fonctionner. 

17. Precede selon I'une quelconque des revendications precedentes, comprenant en outre le controle de I'acces par 
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les dispositifs mobiles a des services a base de paiement sur le reseau d'ordinateurs cable (120, 130, 140), com- 
prenant la collecte des informations de transaction et de facturation associees a la fourniture des ressources sur 
le reseau d'ordinateurs cable (120, 130, 140) aux dispositifs mobiles. 

18. Noeud de reseaux (500, 743) comprenant : 

une premiere interface de communication (748, 1202) pour communiquer avec des dispositifs mobiles de 
communication bidirectionnelle sans fil de donnees de dimension de poche respectifs (1 00, 1 01 ) sur un reseau 
de telecommunications sans fil (110, 111) ; 

une seconde interface de communication (1203) capable de communication avec un serveur (121 , 131, 141) 
sur un reseau d'ordinateurs cable (120, 130, 140) ; et 

un processeur (1204) couple a la premiere interface de communication et a la seconde interface de commu- 
nication pour executer un procede, le procede comprenant les operations consistant a : 

recevoir sur le reseau de telecommunications sans fil une requete provenant d'un dispositif mobile precite 
pour executer une application sur un serveur precite sur le reseau d'ordinateurs cable (120, 130, 140) ; 
adresser la requete sur le reseau d'ordinateurs cable audit serveur pour acceder a ladite application ; 
caracterise par les operations consistant a : 

recevoir une reponse sur le reseau d'ordinateurs cable conformement a I'execution de ladite application 
accedee, la reponse consistant en informations devant etre interpretees par le dispositif mobile et par 
lequel une interface utilisateur interactive est generee a partir de celui-ci et par lequel une autre requete 
est generee a partir de celui-ci vers ledit serveur ou un autre serveur conformement a I'utilisation faite de 
cette interface utilisateur generee ; et 

adresser la reponse a un dispositif mobile precite sur le reseau de telecommunications sans fil. 

19. Noeud de reseaux selon la revendication 18, dans lequel un groupe d'une ou plusieurs interfaces utilisateur inte- 
ractives apparentees est genere a partir desdites informations. 

20. Noeud de reseaux selon la revendication 19, dans lequel I'interface utilisateur interactive ou chaque interface 
utilisateur interactive comprend un ou plusieurs affichages par ecrans (300, 304, 306, 308) sur le dispositif de 
communication mobile (100, 101). 

21. Noeud de reseaux selon I'une des revendications 19 ou 20, comprenant en outre la generation du groupe dyna- 
miquement en reponse a la requete. 

22. Noeud de reseaux selon I'une des revendications 1 9 a 21 , dans lequel une ou plusieurs interfaces utilisateur du 
groupe specifie une ou plusieurs taches devant etre effectuees sur le dispositif de communication mobile (100, 
101). 

23. Noeud de reseaux selon I'une quelconque des revendications 18 a 22 comprenant en outre la conversion de la 
reponse d'un premier langage utilise sur le reseau d'ordinateurs cable (120, 130, 140) a un second langage utilise 
sur le reseau de telecommunications sans fil (110, 111). 

24. Noeud de reseaux selon la revendication 23, dans lequel la reponse comprend un document en langage balise. 

25. Noeud de reseaux selon I'une des revendications 23 ou 24, dans lequel le second langage est une forme distillee 
du premier langage, et dans lequel I'operation consistant a envoyer la reponse traduite au dispositif de communi- 
cation mobile (100, 101) comprend I'operation consistant a envoyer la reponse au dispositif de communication 
mobile (100, 101) dans le second langage sur le reseau de telecommunications sans fil (110, 111) de telle sorte 
que la reponse adressee au dispositif de communication mobile (1 00, 1 01 ) est une forme comprimee de la reponse 
recue par le noeud de reseaux (500, 743) a partir d'un serveur sur le reseau d'ordinateurs cable (120, 130, 140). 

26. Noeud de reseaux selon I'une des revendications 18 a 25, dans lequel le noeud de reseaux (500, 743) comprend 
un serveur de passerelle pour coupler le reseau de telecommunications sans fil (110, 111) au reseau de donnees 
cable. 

27. Noeud de reseaux selon I'une des revendications 18. a 25, dans lequel le noeud de reseaux (500, 743) comprend 
un serveur proxy pour mandater des requetes provenant du dispositif de communication mobile (100, 101) a des 
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serveurs distants sur le reseau d'ordinateurs cable (120, 130, 140). 

28. Noeud de reseaux selon la revendication 18 comprenant en outre les operations consistant a : 

actionner le noeud de reseaux (500, 743) pour communiqueravec le dispositif de communication mobile (100, 
101) sur le reseau de telecommunications sans fil (110, 111, 112) en utilisant un premier protocole ; et 
actionner le noeud de reseaux (500, 743) pour communiquer sur le reseau d'ordinateurs cable (120, 1 30, 140) 
en utilisant un second protocole different du premier protocole. 

29. Noeud de reseaux selon I'une quelconque des revendications 18 a 28, dans lequel le noeud de reseaux (500, 
743) comprend un serveur HTTP. 

30. Noeud de reseaux selon la revendication 29, dans lequel le noeud de reseaux (500, 743) comprend un module 
UDP en plus du serveur HTTP, et dans lequel le serveur HTTP utilise le module UDP pour communiquer des 
donnees avec le reseau de telecommunications sans fil (110, 111). 

31 . Noeud de reseaux selon I'une quelconque des revendications 1 8 a 30, comprenant en outre I'operation consistant 
a controler I'acces a des ressources sur le reseau d'ordinateurs cable (120, 130, 140) par le dispositif de commu- 
nication mobile (100, 101). 

32. Noeud de reseaux selon la revendication 31, dans lequel faire fonctionner le noeud de reseaux (500, 743) pour 
controler I'acces a des ressources sur le reseau d'ordinateurs cable (120, 130, 140) comprend I'operation consis- 
tant a actionner le noeud de reseaux (500, 743) pour autoriser des requetes par le dispositif mobile (100, 101). 

33. Noeud de reseaux selon I'une quelconque des revendications 1 8 a 32, dans lequel le dispositif de communication 
mobile comprend un module de client (702) qui necessite seulement une memoire et une puissance de calcul 
legeres pour fonctionner. 

34. Noeud de reseaux selon I'une quelconque des revendications 18 a 33, comprenant en outre le controle de I'acces 
par les dispositifs mobiles a des services a base de paiement sur le reseau d'ordinateurs cable (120, 130, 140), 
comprenant la collecte des informations de transaction et de facturation associees a la fourniture des ressources 
sur le reseau d'ordinateurs cable (120, 130, 140) aux dispositifs mobiles. 
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